<?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>6</NO>
    <DATE>Tuesday, January 9, 2024</DATE>
    <UNITNAME>Contents</UNITNAME>
    <CNTNTS>
        <AGCY>
            <EAR>
                Agency
                <PRTPAGE P="iii"/>
            </EAR>
            <HD>Agency for International Development</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Workforce and Organizational Surveys, </SJDOC>
                    <PGS>1060</PGS>
                    <FRDOCBP>2024-00207</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Agriculture</EAR>
            <HD>Agriculture Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Animal and Plant Health Inspection Service</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Natural Resources Conservation Service</P>
            </SEE>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>1060-1061</PGS>
                    <FRDOCBP>2024-00226</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>AIRFORCE</EAR>
            <HD>Air Force Department</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>1083</PGS>
                    <FRDOCBP>2024-00254</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Animal</EAR>
            <HD>Animal and Plant Health Inspection Service</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Reclassification:</SJ>
                <SJDENT>
                    <SJDOC>Nuevo Leon, Mexico to Level V for Bovine Tuberculosis, </SJDOC>
                    <PGS>1061</PGS>
                    <FRDOCBP>2024-00265</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Centers Disease</EAR>
            <HD>Centers for Disease Control and Prevention</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Hearings, Meetings, Proceedings, etc., </DOC>
                    <PGS>1095</PGS>
                    <FRDOCBP>2024-00214</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Centers Medicare</EAR>
            <HD>Centers for Medicare &amp; Medicaid Services</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Medicaid and Children's Health Insurance Program, </SJDOC>
                    <PGS>1095-1097</PGS>
                    <FRDOCBP>2024-00205</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Coast Guard</EAR>
            <HD>Coast Guard</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>National Maritime Security Advisory Committee, </SJDOC>
                    <PGS>1111-1112</PGS>
                    <FRDOCBP>2024-00175</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>Industry and Security Bureau</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>Defense Department</EAR>
            <HD>Defense Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Air Force Department</P>
            </SEE>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Acquisition Regulation:</SJ>
                <SJDENT>
                    <SJDOC>Improving Consistency between Procurement and Nonprocurement Procedures on Suspension and Debarment, </SJDOC>
                    <PGS>1043-1053</PGS>
                    <FRDOCBP>2024-00172</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>1083-1086</PGS>
                    <FRDOCBP>2024-00174</FRDOCBP>
                      
                    <FRDOCBP>2024-00256</FRDOCBP>
                      
                    <FRDOCBP>2024-00261</FRDOCBP>
                      
                    <FRDOCBP>2024-00173</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Education Department</EAR>
            <HD>Education Department</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Migrant Student Information Exchange User Application Form, </SJDOC>
                    <PGS>1086</PGS>
                    <FRDOCBP>2024-00255</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>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Civil Monetary Penalty Inflation Adjustment, </DOC>
                    <PGS>1025-1029</PGS>
                    <FRDOCBP>2023-28828</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>National Definition for a Zero Emissions Building:</SJ>
                <SJDENT>
                    <SJDOC>Part 1 Operating Emissions Version 1.00, Draft Criteria, </SJDOC>
                    <PGS>1086-1088</PGS>
                    <FRDOCBP>2024-00203</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Environmental Protection</EAR>
            <HD>Environmental Protection Agency</HD>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <DOCENT>
                    <DOC>Clarifying the Scope of Applicable Requirements under State Operating Permit Programs and the Federal Operating Permit Program, </DOC>
                    <PGS>1150-1189</PGS>
                    <FRDOCBP>2023-27759</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Toxic Substances Control Act New Chemicals Program Decision Framework:</SJ>
                <SJDENT>
                    <SJDOC>Hazard Identification of Eye Irritation and Corrosion, </SJDOC>
                    <PGS>1093-1094</PGS>
                    <FRDOCBP>2024-00169</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Aviation</EAR>
            <HD>Federal Aviation Administration</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>Airworthiness Directives:</SJ>
                <SJDENT>
                    <SJDOC>Lockheed Martin Corporation/Lockheed Martin Aeronautics Company Airplanes, </SJDOC>
                    <PGS>1030-1033</PGS>
                    <FRDOCBP>2024-00300</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Airworthiness Directives:</SJ>
                <SJDENT>
                    <SJDOC>Pratt and Whitney Turbofan Engines, </SJDOC>
                    <PGS>1038-1042</PGS>
                    <FRDOCBP>2024-00309</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Petition for Exemption; Summary:</SJ>
                <SJDENT>
                    <SJDOC>Software Development Alternatives, Inc., </SJDOC>
                    <PGS>1138-1139</PGS>
                    <FRDOCBP>2024-00191</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Deposit</EAR>
            <HD>Federal Deposit Insurance Corporation</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Meetings; Sunshine Act, </DOC>
                    <PGS>1094</PGS>
                    <FRDOCBP>2024-00333</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Emergency</EAR>
            <HD>Federal Emergency Management Agency</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Disaster or Emergency Declaration and Related Determination:</SJ>
                <SJDENT>
                    <SJDOC>Alaska; Amendment No. 2, </SJDOC>
                    <PGS>1118</PGS>
                    <FRDOCBP>2024-00241</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Alaska; Amendment No. 5, </SJDOC>
                    <PGS>1119</PGS>
                    <FRDOCBP>2024-00237</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Arkansas, </SJDOC>
                    <PGS>1118</PGS>
                    <FRDOCBP>2024-00242</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>California, </SJDOC>
                    <PGS>1113</PGS>
                    <FRDOCBP>2024-00244</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Illinois, </SJDOC>
                    <PGS>1115-1116</PGS>
                    <FRDOCBP>2024-00243</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Kentucky; Amendment No. 12, </SJDOC>
                    <PGS>1116</PGS>
                    <FRDOCBP>2024-00234</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Kentucky; Amendment No. 14, </SJDOC>
                    <PGS>1115</PGS>
                    <FRDOCBP>2024-00235</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Kentucky; Amendment No. 2, </SJDOC>
                    <PGS>1112-1113</PGS>
                    <FRDOCBP>2024-00239</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Kentucky; Amendment No. 3, </SJDOC>
                    <PGS>1117</PGS>
                    <FRDOCBP>2024-00238</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Louisiana; Amendment No. 1, </SJDOC>
                    <PGS>1116</PGS>
                    <FRDOCBP>2024-00231</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Louisiana; Amendment No. 2, </SJDOC>
                    <PGS>1116-1117</PGS>
                    <FRDOCBP>2024-00232</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Massachusetts; Amendment No. 1, </SJDOC>
                    <PGS>1113-1114</PGS>
                    <FRDOCBP>2024-00230</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Mississippi; Amendment No. 1, </SJDOC>
                    <PGS>1117</PGS>
                    <FRDOCBP>2024-00229</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Puerto Rico; Amendment No. 18, </SJDOC>
                    <PGS>1113</PGS>
                    <FRDOCBP>2024-00236</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Tennessee, </SJDOC>
                    <PGS>1114-1115</PGS>
                    <FRDOCBP>2024-00245</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <PRTPAGE P="iv"/>
                    <SJDOC>Vermont; Amendment No. 10, </SJDOC>
                    <PGS>1117-1118</PGS>
                    <FRDOCBP>2024-00240</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Virgin Islands, </SJDOC>
                    <PGS>1114</PGS>
                    <FRDOCBP>2024-00233</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Energy</EAR>
            <HD>Federal Energy Regulatory Commission</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Annual Update of Filing Fees, </DOC>
                    <PGS>1033-1034</PGS>
                    <FRDOCBP>2024-00045</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Combined Filings, </DOC>
                    <PGS>1091-1093</PGS>
                    <FRDOCBP>2024-00222</FRDOCBP>
                      
                    <FRDOCBP>2024-00224</FRDOCBP>
                </DOCENT>
                <SJ>Extension of Time:</SJ>
                <SJDENT>
                    <SJDOC>Ozark Gas Transmission, LLC, </SJDOC>
                    <PGS>1090-1091</PGS>
                    <FRDOCBP>2024-00225</FRDOCBP>
                </SJDENT>
                <SJ>Request under Blanket Authorization:</SJ>
                <SJDENT>
                    <SJDOC>Transwestern Pipeline Co., LLC, </SJDOC>
                    <PGS>1088-1090</PGS>
                    <FRDOCBP>2024-00223</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Highway</EAR>
            <HD>Federal Highway Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>1141-1142</PGS>
                    <FRDOCBP>2024-00213</FRDOCBP>
                </DOCENT>
                <SJ>Requests for Nominations:</SJ>
                <SJDENT>
                    <SJDOC>Working Group on Covered Resources, </SJDOC>
                    <PGS>1139-1141</PGS>
                    <FRDOCBP>2024-00251</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Motor</EAR>
            <HD>Federal Motor Carrier Safety Administration</HD>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <DOCENT>
                    <DOC>Fees for the Unified Carrier Registration Plan and Agreement, </DOC>
                    <PGS>1053-1059</PGS>
                    <FRDOCBP>2024-00262</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Exemption Application:</SJ>
                <SJDENT>
                    <SJDOC>Qualification of Drivers; Hearing, </SJDOC>
                    <PGS>1143</PGS>
                    <FRDOCBP>2024-00258</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Reserve</EAR>
            <HD>Federal Reserve System</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Formations of, Acquisitions by, and Mergers of Bank Holding Companies, </DOC>
                    <PGS>1094-1095</PGS>
                    <FRDOCBP>2024-00166</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Fish</EAR>
            <HD>Fish and Wildlife Service</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Endangered and Threatened Species:</SJ>
                <SJDENT>
                    <SJDOC>Initiation of 5-Year Status Reviews of the Aleutian Shield Fern and the Alaska Breeding Population of Steller's Eider, </SJDOC>
                    <PGS>1125-1126</PGS>
                    <FRDOCBP>2024-00257</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Food and Drug</EAR>
            <HD>Food and Drug Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Application for Participation in Food and Drug Administration Fellowship and Traineeship Programs, </SJDOC>
                    <PGS>1100-1101</PGS>
                    <FRDOCBP>2024-00220</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Expedited Programs for Serious Conditions-Drugs and Biologics, </SJDOC>
                    <PGS>1101-1103</PGS>
                    <FRDOCBP>2024-00217</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Extralabel Drug Use in Animals, </SJDOC>
                    <PGS>1099-1100</PGS>
                    <FRDOCBP>2024-00219</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Generic Clearance for the Collection of Qualitative Data on Tobacco Products and Communications, </SJDOC>
                    <PGS>1097-1099</PGS>
                    <FRDOCBP>2024-00221</FRDOCBP>
                </SJDENT>
                <SJ>Priority Review Voucher:</SJ>
                <SJDENT>
                    <SJDOC>Rare Pediatric Disease Product, </SJDOC>
                    <PGS>1097</PGS>
                    <FRDOCBP>2024-00263</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Foreign Trade</EAR>
            <HD>Foreign-Trade Zones Board</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Proposed Production Activity:</SJ>
                <SJDENT>
                    <SJDOC>Twin Disc, Inc., Foreign-Trade Zone 297, Lufkin, TX, </SJDOC>
                    <PGS>1063</PGS>
                    <FRDOCBP>2024-00202</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>General Services</EAR>
            <HD>General Services Administration</HD>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Acquisition Regulation:</SJ>
                <SJDENT>
                    <SJDOC>Improving Consistency between Procurement and Nonprocurement Procedures on Suspension and Debarment, </SJDOC>
                    <PGS>1043-1053</PGS>
                    <FRDOCBP>2024-00172</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Government Accountability</EAR>
            <HD>Government Accountability Office</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Requests for Nominations:</SJ>
                <SJDENT>
                    <SJDOC>Medicare Payment Advisory Commission, </SJDOC>
                    <PGS>1095</PGS>
                    <FRDOCBP>2024-00181</FRDOCBP>
                </SJDENT>
            </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>Health Resources and Services Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>National Institutes of Health</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Substance Abuse and Mental Health Services Administration</P>
            </SEE>
            <CAT>
                <HD>RULES</HD>
                <SJ>Health Data, Technology, and Interoperability:</SJ>
                <SJDENT>
                    <SJDOC>Certification Program Updates, Algorithm Transparency, and Information Sharing, </SJDOC>
                    <PGS>1192-1438</PGS>
                    <FRDOCBP>2023-28857</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Health Resources</EAR>
            <HD>Health Resources and Services Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Bureau of Health Workforce Performance Data Collection, </SJDOC>
                    <PGS>1103-1105</PGS>
                    <FRDOCBP>2024-00210</FRDOCBP>
                </SJDENT>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Advisory Committee on Heritable Disorders in Newborns and Children, </SJDOC>
                    <PGS>1105-1106</PGS>
                    <FRDOCBP>2024-00264</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Homeland</EAR>
            <HD>Homeland Security Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Coast Guard</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Federal Emergency Management Agency</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>Housing</EAR>
            <HD>Housing and Urban Development Department</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Privacy Act; Systems of Records, </DOC>
                    <PGS>1119-1125</PGS>
                    <FRDOCBP>2024-00184</FRDOCBP>
                      
                    <FRDOCBP>2024-00185</FRDOCBP>
                      
                    <FRDOCBP>2024-00186</FRDOCBP>
                </DOCENT>
                <SJ>Requests for Nominations:</SJ>
                <SJDENT>
                    <SJDOC>Manufactured Housing Consensus Committee, </SJDOC>
                    <PGS>1120-1121</PGS>
                    <FRDOCBP>2024-00180</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Industry</EAR>
            <HD>Industry and Security Bureau</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Requests for Nominations:</SJ>
                <SJDENT>
                    <SJDOC>President's Export Council Subcommittee on Export Administration, </SJDOC>
                    <PGS>1064-1065</PGS>
                    <FRDOCBP>2024-00190</FRDOCBP>
                </SJDENT>
            </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>Land Management Bureau</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>Internal Revenue</EAR>
            <HD>Internal Revenue Service</HD>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <DOCENT>
                    <DOC>Taxes on Taxable Distributions from Donor Advised Funds under Section 4966, </DOC>
                    <PGS>1042-1043</PGS>
                    <FRDOCBP>2024-00260</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>International Trade Adm</EAR>
            <HD>International Trade Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Civil Nuclear Trade Advisory Committee, </SJDOC>
                    <PGS>1065</PGS>
                    <FRDOCBP>2024-00196</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Renewable Energy and Energy Efficiency Advisory Committee, </SJDOC>
                    <PGS>1065-1066</PGS>
                    <FRDOCBP>2024-00194</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Labor Department</EAR>
            <HD>Labor Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Occupational Safety and Health Administration</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>Land</EAR>
            <HD>Land Management Bureau</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Public Land Order:</SJ>
                <SJDENT>
                    <SJDOC>No. 7934; Partial Revocation of Four Secretarial Orders for the Grand Valley Reclamation Project and Opening Order; Colorado, </SJDOC>
                    <PGS>1126-1127</PGS>
                    <FRDOCBP>2024-00266</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>
                NASA
                <PRTPAGE P="v"/>
            </EAR>
            <HD>National Aeronautics and Space Administration</HD>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Acquisition Regulation:</SJ>
                <SJDENT>
                    <SJDOC>Improving Consistency between Procurement and Nonprocurement Procedures on Suspension and Debarment, </SJDOC>
                    <PGS>1043-1053</PGS>
                    <FRDOCBP>2024-00172</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Special Events, </SJDOC>
                    <PGS>1130</PGS>
                    <FRDOCBP>2024-00165</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Credit</EAR>
            <HD>National Credit Union Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>1130-1131</PGS>
                    <FRDOCBP>2024-00182</FRDOCBP>
                </DOCENT>
            </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>National Eye Institute, </SJDOC>
                    <PGS>1106</PGS>
                    <FRDOCBP>2024-00212</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>National Institute of Allergy and Infectious Diseases, </SJDOC>
                    <PGS>1107, 1109</PGS>
                    <FRDOCBP>2024-00200</FRDOCBP>
                      
                    <FRDOCBP>2024-00201</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>National Institute of Biomedical Imaging and Bioengineering, </SJDOC>
                    <PGS>1109</PGS>
                    <FRDOCBP>2024-00208</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>National Institute of Dental and Craniofacial Research, </SJDOC>
                    <PGS>1110</PGS>
                    <FRDOCBP>2024-00249</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>National Institute of Mental Health, </SJDOC>
                    <PGS>1106-1107</PGS>
                    <FRDOCBP>2024-00248</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>National Institute on Minority Health and Health Disparities, </SJDOC>
                    <PGS>1107</PGS>
                    <FRDOCBP>2024-00211</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Office of the Director, </SJDOC>
                    <PGS>1108-1109</PGS>
                    <FRDOCBP>2024-00247</FRDOCBP>
                </SJDENT>
                <SJ>Licenses; Exemptions, Applications, Amendments etc.:</SJ>
                <SJDENT>
                    <SJDOC>Development and Commercialization of Thermally Responsive T Cell Therapies for the Treatment of HPV-Positive Cancer(s), </SJDOC>
                    <PGS>1107-1108</PGS>
                    <FRDOCBP>2024-00209</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Oceanic</EAR>
            <HD>National Oceanic and Atmospheric Administration</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Extension of Gulf of Maine Haddock Emergency Action for the Northeast Multispecies Fishery Management Plan, </DOC>
                    <PGS>1036-1037</PGS>
                    <FRDOCBP>2024-00187</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Taking or Importing of Marine Mammals:</SJ>
                <SJDENT>
                    <SJDOC>Hydaburg Seaplane Base Refurbishment Project in Hydaburg, AK, </SJDOC>
                    <PGS>1066-1082</PGS>
                    <FRDOCBP>2024-00189</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Transportation</EAR>
            <HD>National Transportation Safety Board</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Civil Monetary Penalty Inflation Adjustment, </DOC>
                    <PGS>1035-1036</PGS>
                    <FRDOCBP>2024-00228</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Resources</EAR>
            <HD>Natural Resources Conservation Service</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Environmental Assessments; Availability, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Mississippi Trustee Implementation Group Deepwater Horizon Oil Spill Final Restoration Plan 4; Restoration of Wetlands, Coastal, and Nearshore Habitats; Nutrient Reduction (Nonpoint Source); and Provide and Enhance Recreational Opportunities; and Finding of No Significant Impact, </SJDOC>
                    <PGS>1062-1063</PGS>
                    <FRDOCBP>2024-00167</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Occupational Safety Health Adm</EAR>
            <HD>Occupational Safety and Health Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Hydrostatic Testing Provision of the Standard on Portable Fire Extinguishers, </SJDOC>
                    <PGS>1128-1130</PGS>
                    <FRDOCBP>2024-00198</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Standard on Cadmium in General Industries, </SJDOC>
                    <PGS>1127-1128</PGS>
                    <FRDOCBP>2024-00199</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>Disclosure of Termination Information, </SJDOC>
                    <PGS>1131-1132</PGS>
                    <FRDOCBP>2024-00188</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>MEMX LLC, </SJDOC>
                    <PGS>1132-1134</PGS>
                    <FRDOCBP>2024-00178</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Nasdaq BX, Inc., </SJDOC>
                    <PGS>1135-1136</PGS>
                    <FRDOCBP>2024-00176</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Nasdaq PHLX LLC, </SJDOC>
                    <PGS>1136-1138</PGS>
                    <FRDOCBP>2024-00177</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>The Nasdaq Stock Market LLC, </SJDOC>
                    <PGS>1134-1135</PGS>
                    <FRDOCBP>2024-00179</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Substance</EAR>
            <HD>Substance Abuse and Mental Health Services Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Questions from the Task Force on Maternal Mental Health, </DOC>
                    <PGS>1110-1111</PGS>
                    <FRDOCBP>2023-28890</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Trade Representative</EAR>
            <HD>Trade Representative, Office of United States</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>2024 Tariff Rate Quota Quantity Limitations under the U.S.-Australia Free Trade Agreement, </DOC>
                    <PGS>1138</PGS>
                    <FRDOCBP>2024-00227</FRDOCBP>
                </DOCENT>
            </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>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Solicitation for Annual Combating Human Trafficking in Transportation Impact Award, </DOC>
                    <PGS>1143-1147</PGS>
                    <FRDOCBP>2024-00215</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Treasury</EAR>
            <HD>Treasury Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Internal Revenue Service</P>
            </SEE>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Debt Management Advisory Ccommittee, </SJDOC>
                    <PGS>1147</PGS>
                    <FRDOCBP>2024-00218</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Veteran Affairs</EAR>
            <HD>Veterans Affairs Department</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Pilot Program on Graduate Medical Education and Residency, </DOC>
                    <PGS>1034</PGS>
                    <FRDOCBP>2024-00192</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Certification of School Attendance—Restored Entitlement Program for Survivors, </SJDOC>
                    <PGS>1147-1148</PGS>
                    <FRDOCBP>2024-00216</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <PTS>
            <HD SOURCE="HED">Separate Parts In This Issue</HD>
            <HD>Part II</HD>
            <DOCENT>
                <DOC>Environmental Protection Agency, </DOC>
                <PGS>1150-1189</PGS>
                <FRDOCBP>2023-27759</FRDOCBP>
            </DOCENT>
            <HD>Part III</HD>
            <DOCENT>
                <DOC>Health and Human Services Department, </DOC>
                <PGS>1192-1438</PGS>
                <FRDOCBP>2023-28857</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>6</NO>
    <DATE>Tuesday, January 9, 2024</DATE>
    <UNITNAME>Rules and Regulations</UNITNAME>
    <RULES>
        <RULE>
            <PREAMB>
                <PRTPAGE P="1025"/>
                <AGENCY TYPE="F">DEPARTMENT OF ENERGY</AGENCY>
                <CFR>10 CFR Parts 207, 218, 429, 431, 490, 501, 601, 810, 820, 824, 851, 1013, 1017, and 1050</CFR>
                <SUBJECT>Inflation Adjustment of Civil Monetary Penalties</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the General Counsel, U.S. Department of Energy.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Department of Energy (“DOE”) publishes this final rule to adjust DOE's civil monetary penalties (“CMPs”) for inflation as mandated by the Federal Civil Penalties Inflation Adjustment Act of 1990, as further amended by the Federal Civil Penalties Inflation Adjustment Act Improvements Act of 2015 (collectively referred to herein as “the Act”). This rule adjusts CMPs within the jurisdiction of DOE to the maximum amount required by the Act.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This rule is effective on January 9, 2024.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Preeti Chaudhari, U.S. Department of Energy, Office of the General Counsel, GC-33, 1000 Independence Avenue SW, Washington, DC 20585, (202) 586-8078, 
                        <E T="03">preeti.chaudhari@hq.doe.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. Background</FP>
                    <FP SOURCE="FP-2">II. Method of Calculation</FP>
                    <FP SOURCE="FP-2">III. Summary of the Final Rule</FP>
                    <FP SOURCE="FP-2">IV. Final Rulemaking</FP>
                    <FP SOURCE="FP-2">V. Regulatory Review</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. Background</HD>
                <P>In order to improve the effectiveness of CMPs and to maintain their deterrent effect, the Federal Civil Penalties Inflation Adjustment Act of 1990, 28 U.S.C. 2461 note (“the Inflation Adjustment Act”), as further amended by the Federal Civil Penalties Inflation Adjustment Act Improvements Act of 2015 (Pub. L. 114-74) (“the 2015 Act”), requires Federal agencies to adjust each CMP provided by law within the jurisdiction of the agency. The 2015 Act required agencies to adjust the level of CMPs with an initial “catch-up” adjustment through an interim final rulemaking and to make subsequent annual adjustments for inflation, notwithstanding 5 U.S.C. 553. DOE's initial catch-up adjustment interim final rule was published June 28, 2016 (81 FR 41790), and adopted as final without amendment on December 30, 2016 (81 FR 96349). The 2015 Act also provides that any increase in a CMP shall apply only to CMPs, including those whose associated violation predated such increase, which are assessed after the date the increase takes effect.</P>
                <P>
                    In accordance with the 2015 Act, the Office of Management and Budget (OMB) must issue annually guidance on adjustments to civil monetary penalties. This final rule to adjust civil monetary penalties for 2024 is issued in accordance with applicable law and OMB's guidance memorandum on implementation of the 2024 annual adjustment.
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         OMB's annual guidance memorandum was issued on December 19, 2023, providing the 2024 adjustment multiplier and addressing how to apply it.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">II. Method of Calculation</HD>
                <P>The method of calculating CMP adjustments applied in this final rule is required by the 2015 Act. Under the 2015 Act, annual inflation adjustments subsequent to the initial catch-up adjustment are to be based on the percent change between the October Consumer Price Index for all Urban Consumers (CPI-U) preceding the date of the adjustment, and the prior year's October CPI-U. Pursuant to the aforementioned OMB guidance memorandum, the adjustment multiplier for 2024 is 1.03241. In order to complete the 2024 annual adjustment, each CMP is multiplied by the 2024 adjustment multiplier. Under the 2015 Act, any increase in CMP must be rounded to the nearest multiple of $1.</P>
                <HD SOURCE="HD1">III. Summary of the Final Rule</HD>
                <P>
                    The following list summarizes DOE authorities containing CMPs, and the penalties before and after adjustment.
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         The CMP authority formerly listed as 42 U.S.C. 2282(a) was codified in 10 CFR 810.15 (88 FR 1973, January 12, 2023).
                    </P>
                </FTNT>
                <GPOTABLE COLS="3" OPTS="L2,tp0,i1" CDEF="s100,xs90,xs90">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">DOE authority containing civil monetary penalty</CHED>
                        <CHED H="1">Before adjustment</CHED>
                        <CHED H="1">After adjustment</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">10 CFR 207.7</ENT>
                        <ENT>$12,531</ENT>
                        <ENT>$12,937.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10 CFR 218.42</ENT>
                        <ENT>$27,140</ENT>
                        <ENT>$28,020.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10 CFR 429.120</ENT>
                        <ENT>$542</ENT>
                        <ENT>$560.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10 CFR 431.382</ENT>
                        <ENT>$542</ENT>
                        <ENT>$560.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10 CFR 490.604</ENT>
                        <ENT>$10,506</ENT>
                        <ENT>$10,846.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10 CFR 501.181</ENT>
                        <ENT>
                            —$111,031
                            <LI>—$9/mcf</LI>
                            <LI>—$44/bbl</LI>
                        </ENT>
                        <ENT>
                            —$114,630.
                            <LI>—$9/mcf.</LI>
                            <LI>—$45/bbl.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10 CFR 601.400 and appendix A</ENT>
                        <ENT>
                            —minimum $23,727
                            <LI>—maximum $237,268</LI>
                        </ENT>
                        <ENT>
                            —minimum $24,496.
                            <LI>—maximum $244,958.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            10 CFR 810.15 
                            <SU>2</SU>
                        </ENT>
                        <ENT>$120,816</ENT>
                        <ENT>$124,732.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10 CFR 820.81</ENT>
                        <ENT>$247,929</ENT>
                        <ENT>$255,964.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10 CFR 824.1</ENT>
                        <ENT>$177,174</ENT>
                        <ENT>$182,916.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10 CFR 824.4</ENT>
                        <ENT>$177,174</ENT>
                        <ENT>$182,916.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10 CFR 851.5 and appendix B</ENT>
                        <ENT>$115,061</ENT>
                        <ENT>$118,790.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10 CFR 1013.3</ENT>
                        <ENT>$13,508</ENT>
                        <ENT>$13,946.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10 CFR 1017.29</ENT>
                        <ENT>$319,067</ENT>
                        <ENT>$329,408.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10 CFR 1050.303</ENT>
                        <ENT>$24,189</ENT>
                        <ENT>$24,973.</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="1026"/>
                        <ENT I="01">
                            50 U.S.C. 2731 
                            <SU>3</SU>
                        </ENT>
                        <ENT>$10,846</ENT>
                        <ENT>$11,198.</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">
                    IV. Final Rulemaking
                    <FTREF/>
                </HD>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         Implemented by 10 CFR 820.81, 10 CFR 851.5, and appendix B to 10 CFR part 851.
                    </P>
                </FTNT>
                <P>The 2015 Act requires that annual adjustments for inflation subsequent to the initial “catch-up” adjustment be made notwithstanding 5 U.S.C. 553.</P>
                <HD SOURCE="HD1">V. Regulatory Review</HD>
                <HD SOURCE="HD2">A. Executive Order 12866, 13563, and 14094</HD>
                <P>This final rule has been determined not to be a significant regulatory action under Executive Order 12866, “Regulatory Planning and Review,” 58 FR 51735 (October 4, 1993), as supplemented and reaffirmed by E.O. 13563, “Improving Regulation and Regulatory Review,” 76 FR 3821 (Jan. 21, 2011) and amended by E.O. 14094, “Modernizing Regulatory Review,” 88 FR 21879 (April 11, 2023). Accordingly, this action was not subject to review under that Executive order by the Office of Information and Regulatory Affairs of the Office of Management and Budget.</P>
                <HD SOURCE="HD2">B. National Environmental Policy Act</HD>
                <P>DOE has determined that this final rule is covered under the Categorical Exclusion found in DOE's National Environmental Policy Act regulations at paragraph A5 of appendix A to subpart D, 10 CFR part 1021, which applies to a rulemaking that amends an existing rule or regulation and that does not change the environmental effect of the rule or regulation being amended. Accordingly, neither an environmental assessment nor an environmental impact statement is required.</P>
                <HD SOURCE="HD2">C. Regulatory Flexibility Act</HD>
                <P>
                    The Regulatory Flexibility Act (5 U.S.C. 601 
                    <E T="03">et seq.)</E>
                     requires preparation of an initial regulatory flexibility analysis for any rule that by law must be proposed for public comment. As discussed previously, the 2015 Act requires that annual inflation adjustments subsequent to the initial catch-up adjustment be made notwithstanding 5 U.S.C. 553. Because a notice of proposed rulemaking is not required for this action pursuant to 5 U.S.C. 553, or any other law, no regulatory flexibility analysis has been prepared for this final rule.
                </P>
                <HD SOURCE="HD2">D. Paperwork Reduction Act</HD>
                <P>This final rule imposes no new information collection requirements subject to the Paperwork Reduction Act.  </P>
                <HD SOURCE="HD2">E. Unfunded Mandates Reform Act of 1995</HD>
                <P>The Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4) generally requires Federal agencies to examine closely the impacts of regulatory actions on State, local, and tribal governments. Section 201 excepts agencies from assessing effects on State, local or tribal governments or the private sector of rules that incorporate requirements specifically set forth in law. Because this rule incorporates requirements specifically set forth in 28 U.S.C. 2461 note, DOE is not required to assess its regulatory effects under section 201. Unfunded Mandates Reform Act sections 202 and 205 do not apply to this action because they apply only to rules for which a general notice of proposed rulemaking is published. Nevertheless, DOE has determined that this regulatory action does not impose a Federal mandate on State, local, or tribal governments or on the public sector.</P>
                <HD SOURCE="HD2">F. Treasury and General Government Appropriations Act, 1999</HD>
                <P>Section 654 of the Treasury and General Government Appropriations Act, 1999 (Pub. L. 105-277) requires Federal agencies to issue a Family Policymaking Assessment for any proposed rule that may affect family well-being. This final rule would not have any impact on the autonomy or integrity of the family as an institution. Accordingly, DOE has concluded that it is not necessary to prepare a Family Policymaking Assessment.</P>
                <HD SOURCE="HD2">G. Executive Order 13132</HD>
                <P>Executive Order 13132, “Federalism,” 64 FR 43255 (August 4, 1999) imposes certain requirements on agencies formulating and implementing policies or regulations that preempt State law or that have federalism implications. Agencies are required to examine the constitutional and statutory authority supporting any action that would limit the policymaking discretion of the States and carefully assess the necessity for such actions. DOE has examined this rule and has determined that it would not preempt State law and would not have a substantial direct effect on the States, on the relationship between the National Government and the States, or on the distribution of power and responsibilities among the various levels of government. No further action is required by Executive Order 13132.</P>
                <HD SOURCE="HD2">H. Executive Order 12988</HD>
                <P>With respect to the review of existing regulations and the promulgation of new regulations, section 3(a) of Executive Order 12988, “Civil Justice Reform,” 61 FR 4729 (February 7, 1996), imposes on executive agencies the general duty to adhere to the following requirements: (1) eliminate drafting errors and ambiguity; (2) write regulations to minimize litigation; and (3) provide a clear legal standard for affected conduct rather than a general standard and promote simplification and burden reduction. With regard to the review required by section 3(a), section 3(b) of Executive Order 12988 specifically requires that Executive agencies make every reasonable effort to ensure that the regulation: (1) clearly specifies the preemptive effect, if any; (2) clearly specifies any effect on existing Federal law or regulation; (3) provides a clear legal standard for affected conduct while promoting simplification and burden reduction; (4) specifies the retroactive effect, if any; (5) adequately defines key terms; and (6) addresses other important issues affecting clarity and general draftsmanship under any guidelines issued by the Attorney General. Section 3(c) of Executive Order 12988 requires executive agencies to review regulations in light of applicable standards in section 3(a) and section 3(b) to determine whether they are met or it is unreasonable to meet one or more of them. DOE has completed the required review and determined that, to the extent permitted by law, this rule meets the relevant standards of Executive Order 12988.</P>
                <HD SOURCE="HD2">I. Treasury and General Government Appropriations Act, 2001</HD>
                <P>
                    The Treasury and General Government Appropriations Act, 2001 (44 U.S.C. 3516 note) provides for agencies to review most disseminations of information to the public under guidelines established by each agency pursuant to general guidelines issued by OMB. OMB's guidelines were published at 67 FR 8452 (February 22, 2002), and DOE's guidelines were published at 67 FR 62446 (October 7, 2002). DOE has 
                    <PRTPAGE P="1027"/>
                    reviewed this final rule under the OMB and DOE guidelines and has concluded that it is consistent with applicable policies in those guidelines.
                </P>
                <HD SOURCE="HD2">J. Executive Order 13211</HD>
                <P>Executive Order 13211, “Actions Concerning Regulations That Significantly Affect Energy Supply, Distribution, or Use,” 66 FR 28355 (May 22, 2001) requires Federal agencies to prepare and submit to OMB, a Statement of Energy Effects for any proposed significant energy action. A “significant energy action” is defined as any action by an agency that promulgated or is expected to lead to promulgation of a final rule, and that: (1) is a significant regulatory action under Executive Order 12866, or any successor order; and (2) is likely to have a significant adverse effect on the supply, distribution, or use of energy, or (3) is designated by the Administrator of the Office of Information and Regulatory Affairs (OIRA) as a significant energy action. For any proposed significant energy action, the agency must give a detailed statement of any adverse effects on energy supply, distribution, or use should the proposal be implemented, and of reasonable alternatives to the action and their expected benefits on energy supply, distribution, and use. This regulatory action would not have a significant adverse effect on the supply, distribution, or use of energy and is therefore not a significant energy action. Accordingly, DOE has not prepared a Statement of Energy Effects.</P>
                <HD SOURCE="HD2">K. Congressional Notification</HD>
                <P>As required by 5 U.S.C. 801, DOE will submit to Congress a report regarding the issuance of this final rule prior to the effective date set forth at the outset of this rulemaking. The report will state that it has been determined that the rule is not a “major rule” as defined by 5 U.S.C. 801(2).  </P>
                <HD SOURCE="HD2">L. Approval of the Office of the Secretary</HD>
                <P>The Secretary of Energy has approved publication of this final rule.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects</HD>
                    <CFR>10 CFR Part 207</CFR>
                    <P>Administrative practice and procedure, Energy, Penalties.</P>
                    <CFR>10 CFR Part 218</CFR>
                    <P>Administrative practice and procedure, Penalties, Petroleum allocation.</P>
                    <CFR>10 CFR Part 429</CFR>
                    <P>Confidential business information, Energy conservation, Household appliances, Imports, Reporting and recordkeeping requirements.</P>
                    <CFR>10 CFR Part 431</CFR>
                    <P>Administrative practices and procedure, Confidential business information, Energy conservation, Reporting and recordkeeping requirements.</P>
                    <CFR>10 CFR Part 490</CFR>
                    <P>Administrative practice and procedure, Energy conservation, Penalties.</P>
                    <CFR>10 CFR Part 501</CFR>
                    <P>Administrative practice and procedure, Electric power plants, Energy conservation, Natural gas, Petroleum.</P>
                    <CFR>10 CFR Part 601</CFR>
                    <P>Government contracts, Grant programs, Loan programs, Penalties.</P>
                    <CFR>10 CFR Part 810</CFR>
                    <P>Foreign relations, Nuclear energy, Reporting and recordkeeping requirements.</P>
                    <CFR>10 CFR Part 820</CFR>
                    <P>Administrative practice and procedure, Government contracts, Penalties, Radiation protection.</P>
                    <CFR>10 CFR Part 824</CFR>
                    <P>Government contracts, Nuclear materials, Penalties, Security measures.</P>
                    <CFR>10 CFR Part 851</CFR>
                    <P>Civil penalty, Hazardous substances, Occupational safety and health, Safety, Reporting and recordkeeping requirements.</P>
                    <CFR>10 CFR Part 1013</CFR>
                    <P>Administrative practice and procedure, Claims, Fraud, Penalties.</P>
                    <CFR>10 CFR Part 1017</CFR>
                    <P>Administrative practice and procedure, Government contracts, National defense, Nuclear energy, Penalties, Security measures.</P>
                    <CFR>10 CFR Part 1050</CFR>
                    <P>Decorations, medals, awards, Foreign relations, Government employees, Government property, Reporting and recordkeeping requirements.</P>
                </LSTSUB>
                <HD SOURCE="HD1">Signing Authority</HD>
                <P>
                    This document of the Department of Energy was signed on December 22, 2023, by Samuel Walsh, General Counsel, pursuant to delegated authority from the Secretary of Energy. That document with the original signature and date is maintained by DOE. For administrative purposes only, and in compliance with requirements of the Office of the Federal Register, the undersigned DOE Federal Register Liaison Officer has been authorized to sign and submit the document in electronic format for publication, as an official document of the Department of Energy. This administrative process in no way alters the legal effect of this document upon publication in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <SIG>
                    <DATED>Signed in Washington, DC, on December 27, 2023.</DATED>
                    <NAME>Treena V. Garrett,</NAME>
                    <TITLE>Federal Register Liaison Officer, U.S. Department of Energy.</TITLE>
                </SIG>
                <P>For the reasons set forth in the preamble, DOE amends chapters II, III, and X of title 10 of the Code of Federal Regulations as set forth below.</P>
                <PART>
                    <HD SOURCE="HED">PART 207—COLLECTION OF INFORMATION</HD>
                </PART>
                <REGTEXT TITLE="10" PART="207">
                    <AMDPAR>1. The authority citation for part 207 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                             15 U.S.C. 787 
                            <E T="03">et seq.;</E>
                             15 U.S.C. 791 
                            <E T="03">et seq.;</E>
                             E.O. 11790, 39 FR 23185; 28 U.S.C. 2461 note.
                        </P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="207">
                    <AMDPAR>2. Section 207.7 is amended by revising the first sentence of paragraph (c)(1) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 207.7</SECTNO>
                        <SUBJECT>Sanctions.</SUBJECT>
                        <STARS/>
                        <P>(c) * * *</P>
                        <P>(1) Any person who violates any provision of this subpart or any order issued pursuant thereto shall be subject to a civil penalty of not more than $12,937 for each violation. * * *</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 218—STANDBY MANDATORY INTERNATIONAL OIL ALLOCATION</HD>
                </PART>
                <REGTEXT TITLE="10" PART="218">
                    <AMDPAR>3. The authority citation for part 218 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                             15 U.S.C. 751 
                            <E T="03">et seq.;</E>
                             15 U.S.C. 787 
                            <E T="03">et seq.;</E>
                             42 U.S.C. 6201 
                            <E T="03">et seq.;</E>
                             42 U.S.C. 7101 
                            <E T="03">et seq.;</E>
                             E.O. 11790, 39 FR 23185; E.O. 12009, 42 FR 46267; 28 U.S.C. 2461 note.
                        </P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="218">
                    <AMDPAR>4. Section 218.42 is amended by revising paragraph (b)(1) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 218.42</SECTNO>
                        <SUBJECT>Sanctions.</SUBJECT>
                        <STARS/>
                        <P>(b) * * *</P>
                        <P>(1) Any person who violates any provision of this part or any order issued pursuant thereto shall be subject to a civil penalty of not more than $28,020 for each violation.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <PRTPAGE P="1028"/>
                    <HD SOURCE="HED">PART 429—CERTIFICATION, COMPLIANCE, AND ENFORCEMENT FOR CONSUMER PRODUCTS AND COMMERCIAL AND INDUSTRIAL EQUIPMENT</HD>
                </PART>
                <REGTEXT TITLE="10" PART="429">
                    <AMDPAR>5. The authority citation for part 429 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P> 42 U.S.C. 6291-6317; 28 U.S.C. 2461 note.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="429">
                    <AMDPAR>6. Section 429.120 is amended by revising the first sentence to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 429.120</SECTNO>
                        <SUBJECT>Maximum civil penalty.</SUBJECT>
                        <P>Any person who knowingly violates any provision of § 429.102(a) may be subject to assessment of a civil penalty of no more than $560 for each violation. * * *</P>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 431—ENERGY EFFICIENCY PROGRAM FOR CERTAIN COMMERCIAL AND INDUSTRIAL EQUIPMENT</HD>
                </PART>
                <REGTEXT TITLE="10" PART="431">
                    <AMDPAR>7. The authority citation for part 431 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P> 42 U.S.C. 6291-6317; 28 U.S.C. 2461 note.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="431">
                    <AMDPAR>8. Section 431.382 is amended by revising paragraph (b) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 431.382</SECTNO>
                        <SUBJECT>Prohibited acts.</SUBJECT>
                        <STARS/>
                        <P>(b) In accordance with sections 333 and 345 of the Act, any person who knowingly violates any provision of paragraph (a) of this section may be subject to assessment of a civil penalty of no more than $560 for each violation.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 490—ALTERNATIVE FUEL TRANSPORTATION PROGRAM</HD>
                </PART>
                <REGTEXT TITLE="10" PART="490">
                    <AMDPAR>9. The authority citation for part 490 continues to read as follows:  </AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                             42 U.S.C. 7191 
                            <E T="03">et seq.;</E>
                             42 U.S.C. 13201, 13211, 13220, 13251 
                            <E T="03">et seq.</E>
                             28 U.S.C. 2461 note.
                        </P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="490">
                    <AMDPAR>10. Section 490.604 is amended by revising paragraph (a) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 490.604</SECTNO>
                        <SUBJECT>Penalties and Fines.</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">Civil penalties.</E>
                             Whoever violates § 490.603 shall be subject to a civil penalty of not more than $10,846 for each violation.
                        </P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 501—ADMINISTRATIVE PROCEDURES AND SANCTIONS</HD>
                </PART>
                <REGTEXT TITLE="10" PART="501">
                    <AMDPAR>11. The authority citation for part 501 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                             42 U.S.C. 7101 
                            <E T="03">et seq.;</E>
                             42 U.S.C. 8301 
                            <E T="03">et seq.;</E>
                             42 U.S.C. 8701 
                            <E T="03">et seq.;</E>
                             E.O. 12009, 42 FR 46267; 28 U.S.C. 2461 note.
                        </P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="501">
                    <AMDPAR>12. Section 501.181 is amended by revising paragraph (c)(1) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 501.181</SECTNO>
                        <SUBJECT>Sanctions.</SUBJECT>
                        <STARS/>
                        <P>(c) * * *</P>
                        <P>(1) Any person who violates any provisions of the Act (other than section 402) or any rule in this subchapter or order under this subchapter or the Act will be subject to the following civil penalty, which may not exceed $114,630 for each violation: Any person who operates a powerplant or major fuel burning installation under an exemption, during any 12-calendar-month period, in excess of that authorized in such exemption will be assessed a civil penalty of up to $9 for each MCF of natural gas or up to $45 for each barrel of oil used in excess of that authorized in the exemption.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 601—NEW RESTRICTIONS ON LOBBYING</HD>
                </PART>
                <REGTEXT TITLE="10" PART="601">
                    <AMDPAR>13. The authority citation for part 601 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P> 31 U.S.C. 1352; 42 U.S.C. 7254 and 7256; 31 U.S.C. 6301-6308; 28 U.S.C. 2461 note.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="601">
                    <AMDPAR>14. Section 601.400 is amended by revising paragraphs (a), (b), and (e) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 601.400</SECTNO>
                        <SUBJECT>Penalties.</SUBJECT>
                        <P>(a) Any person who makes an expenditure prohibited by this part shall be subject to a civil penalty of not less than $24,496 and not more than $244,958 for each such expenditure.</P>
                        <P>(b) Any person who fails to file or amend the disclosure form (see appendix B to this part) to be filed or amended if required by this part, shall be subject to a civil penalty of not less than $24,496 and not more than $244,958 for each such failure.</P>
                        <STARS/>
                        <P>(e) First offenders under paragraph (a) or (b) of this section shall be subject to a civil penalty of $24,496, absent aggravating circumstances. Second and subsequent offenses by persons shall be subject to an appropriate civil penalty between $24,496 and $244,958, as determined by the agency head or his or her designee.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <HD SOURCE="HD1">Appendix A to Part 601 [Amended]</HD>
                <REGTEXT TITLE="10" PART="601">
                    <AMDPAR>15. Appendix A to part 601 is amended by:</AMDPAR>
                    <AMDPAR>a. Removing “$23,727” wherever it appears and adding in its place “$24,496”; and</AMDPAR>
                    <AMDPAR>b. Removing “$237,268” wherever it appears and adding in its place “$244,958”.</AMDPAR>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 810—ASSISTANCE TO FOREIGN ATOMIC ENERGY ACTIVITIES</HD>
                </PART>
                <REGTEXT TITLE="10" PART="810">
                    <AMDPAR>16. The authority citation for part 810 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                             Secs. 57, 127, 128, 129, 161, 222, 232, and 234 AEA, as amended by the 
                            <E T="03">Nuclear Nonproliferation Act of 1978,</E>
                             Pub. L. 95-242, 68 Stat. 932, 948, 950, 958, 92 Stat. 126, 136, 137, 138 (42 U.S.C. 2077, 2156, 2157, 2158, 2201, 2272, 2280, 2282), the 
                            <E T="03">Intelligence Reform and Terrorism Prevention Act of 2004,</E>
                             Pub. L. 108-458, 118 Stat. 3768, and sec. 3116 of the 
                            <E T="03">John S. McCain National Defense Authorization Act for Fiscal Year 2019,</E>
                             Pub. L. 115-232; Sec. 104 of the 
                            <E T="03">Energy Reorganization Act of 1974,</E>
                             Pub. L. 93-438; Sec. 301, 
                            <E T="03">Department of Energy Organization Act,</E>
                             Pub. L. 95-91; 
                            <E T="03">National Nuclear Security Administration Act,</E>
                             Pub. L. 106-65, 50 U.S.C. 2401 
                            <E T="03">et seq.,</E>
                             as amended.
                        </P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="810">
                    <AMDPAR>17. Section 810.15 is amended by revising the introductory text of paragraph (c) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 810.15</SECTNO>
                        <SUBJECT>Violations.</SUBJECT>
                        <STARS/>
                        <P>(c) In accordance with section 234 of the AEA, any person who violates any provision of section 57 b. of the AEA, as implemented under this part, shall be subject to a civil penalty, not to exceed $124,732 per violation, such amount to be adjusted annually for inflation pursuant to the Federal Civil Penalties Inflation Adjustment Act Improvements Act of 2015. If any violation is a continuing one, each day from the point at which the violating activity began to the point at which the violating activity was suspended shall constitute a separate violation for the purpose of computing the applicable civil penalty. The mere act of suspending an activity does not constitute admission that the activity was a violation and does not waive the rights and processes outlined in paragraphs (c)(4) through (14) of this section or otherwise impact the right of the person to appeal any civil penalty that may be imposed.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 820—PROCEDURAL RULES FOR DOE NUCLEAR ACTIVITIES</HD>
                </PART>
                <REGTEXT TITLE="10" PART="820">
                    <AMDPAR>18. The authority citation for part 820 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P> 42 U.S.C. 2201; 2282(a); 7191; 28 U.S.C. 2461 note; 50 U.S.C. 2410.  </P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="820">
                    <PRTPAGE P="1029"/>
                    <AMDPAR>19. Section 820.81 is amended by revising the first sentence to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 820.81</SECTNO>
                        <SUBJECT>Amount of penalty.</SUBJECT>
                        <P>Any person subject to a penalty under 42 U.S.C. 2282a shall be subject to a civil penalty in an amount not to exceed $255,964 for each such violation. * * * </P>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 824—PROCEDURAL RULES FOR THE ASSESSMENT OF CIVIL PENALTIES FOR CLASSIFIED INFORMATION SECURITY VIOLATIONS</HD>
                </PART>
                <REGTEXT TITLE="10" PART="824">
                    <AMDPAR>20. The authority citation for part 824 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                             42 U.S.C. 2201, 2282b, 7101 
                            <E T="03">et seq.,</E>
                             50 U.S.C. 2401 
                            <E T="03">et seq.;</E>
                             28 U.S.C. 2461 note.
                        </P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="824">
                    <AMDPAR>21. Section 824.1 is amended by revising the second sentence to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 824.1</SECTNO>
                        <SUBJECT>Purpose and scope.</SUBJECT>
                        <P>* * * Subsection a. provides that any person who has entered into a contract or agreement with the Department of Energy, or a subcontract or subagreement thereto, and who violates (or whose employee violates) any applicable rule, regulations in this chapter, or order under the Act relating to the security or safeguarding of Restricted Data or other classified information, shall be subject to a civil penalty not to exceed $182,916 for each violation. * * * </P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="824">
                    <AMDPAR>22. Section 824.4 is amended by revising paragraph (c) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 824.4 Civil</SECTNO>
                        <SUBJECT>penalties.</SUBJECT>
                        <STARS/>
                        <P>(c) The Director may propose imposition of a civil penalty for violation of a requirement of a regulation or rule under paragraph (a) of this section or a compliance order issued under paragraph (b) of this section, not to exceed $182,916 for each violation.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 851—WORKER SAFETY AND HEALTH PROGRAM</HD>
                </PART>
                <REGTEXT TITLE="10" PART="851">
                    <AMDPAR>23. The authority citation for part 851 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                             42 U.S.C. 2201(i)(3), (p); 42 U.S.C. 2282c; 42 U.S.C. 5801 
                            <E T="03">et seq.;</E>
                             42 U.S.C. 7101 
                            <E T="03">et seq.;</E>
                             50 U.S.C. 2401 
                            <E T="03">et seq.;</E>
                             28 U.S.C. 2461 note.
                        </P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="851">
                    <AMDPAR>24. Section 851.5 is amended by revising the first sentence of paragraph (a) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 851.5</SECTNO>
                        <SUBJECT>Enforcement.</SUBJECT>
                        <P>(a) A contractor that is indemnified under section 170d. of the AEA (or any subcontractor or supplier thereto) and that violates (or whose employee violates) any requirement of this part shall be subject to a civil penalty of up to $118,790 for each such violation. * * *</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="851">
                    <AMDPAR>25. Appendix B to part 851 is amended by:</AMDPAR>
                    <AMDPAR>a. Revising the last sentences of paragraphs (b)(1) and (2) in section VI; and</AMDPAR>
                    <AMDPAR>b. Revising paragraph 1.(e)(1) in section IX.</AMDPAR>
                    <P>The revisions read as follows:</P>
                    <HD SOURCE="HD1">Appendix B to Part 851—General Statement of Enforcement Policy </HD>
                    <EXTRACT>
                        <STARS/>
                        <FP SOURCE="FP-1">
                            <E T="03">VI. Severity of Violations</E>
                        </FP>
                        <STARS/>
                        <P>(b) * * *</P>
                        <P>(1) * * * A Severity Level I violation would be subject to a base civil penalty of up to 100% of the maximum base civil penalty of $118,790.</P>
                        <P>(2) * * * A Severity Level II violation would be subject to a base civil penalty up to 50% of the maximum base civil penalty ($59,395).</P>
                        <STARS/>
                        <FP SOURCE="FP-1">
                            <E T="03">IX. Enforcement Actions</E>
                        </FP>
                        <STARS/>
                        <FP>
                            <E T="03">1. Notice of Violation</E>
                        </FP>
                        <STARS/>
                        <P>(e) * * *</P>
                        <P>
                            (1) DOE may assess civil penalties of up to $118,790 per violation per day on contractors (and their subcontractors and suppliers) that are indemnified by the Price-Anderson Act, 42 U.S.C. 2210(d). 
                            <E T="03">See</E>
                             10 CFR 851.5(a).
                        </P>
                    </EXTRACT>
                    <STARS/>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 1013—PROGRAM FRAUD CIVIL REMEDIES AND PROCEDURES</HD>
                </PART>
                <REGTEXT TITLE="10" PART="813">
                    <AMDPAR>26. The authority citation for part 1013 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P> 31 U.S.C. 3801-3812; 28 U.S.C. 2461 note.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="1013">
                    <AMDPAR>27. Section 1013.3 is amended by revising paragraphs (a)(1)(iv) and (b)(1)(ii) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 1013.3</SECTNO>
                        <SUBJECT>Basis for civil penalties and assessments.</SUBJECT>
                        <P>(a) * * *</P>
                        <P>(1) * * *</P>
                        <P>(iv) Is for payment for the provision of property or services which the person has not provided as claimed, shall be subject, in addition to any other remedy that may be prescribed by law, to a civil penalty of not more than $13,946 for each such claim.</P>
                        <STARS/>
                        <P>(b) * * *</P>
                        <P>(1) * * *</P>
                        <P>(ii) Contains or is accompanied by an express certification or affirmation of the truthfulness and accuracy of the contents of the statement, shall be subject, in addition to any other remedy that may be prescribed by law, to a civil penalty of not more than $13,946 for each such statement.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 1017—IDENTIFICATION AND PROTECTION OF UNCLASSIFIED CONTROLLED NUCLEAR INFORMATION</HD>
                </PART>
                <REGTEXT TITLE="10" PART="1017">
                    <AMDPAR>28. The authority citation for part 1017 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                             42 U.S.C. 7101 
                            <E T="03">et seq.;</E>
                             50 U.S.C. 2401 
                            <E T="03">et seq.;</E>
                             42 U.S.C. 2168; 28 U.S.C. 2461 note.
                        </P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="1017">
                    <AMDPAR>29. Section 1017.29 is amended by revising paragraph (c) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 1017.29</SECTNO>
                        <SUBJECT>Civil penalty.</SUBJECT>
                        <STARS/>
                        <P>
                            (c) 
                            <E T="03">Amount of penalty.</E>
                             The Director may propose imposition of a civil penalty for violation of a requirement of a regulation under paragraph (a) of this section or a compliance order issued under paragraph (b) of this section, not to exceed $329,408 for each violation.
                        </P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 1050—FOREIGN GIFTS AND DECORATIONS</HD>
                </PART>
                <REGTEXT TITLE="10" PART="1050">
                    <AMDPAR>30. The authority citation for part 1050 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P> The Constitution of the United States, Article I, Section 9; 5 U.S.C. 7342; 22 U.S.C. 2694; 42 U.S.C. 7254 and 7262; 28 U.S.C. 2461 note.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="10" PART="1050">
                    <AMDPAR>31. Section 1050.303 is amended by revising the last sentence in paragraph (d) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 1050.303</SECTNO>
                        <SUBJECT>Enforcement.</SUBJECT>
                        <STARS/>
                        <P>(d) * * * The court in which such action is brought may assess a civil penalty against such employee in any amount not to exceed the retail value of the gift improperly solicited or received plus $24,973.</P>
                    </SECTION>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2023-28828 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6450-01-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <PRTPAGE P="1030"/>
                <AGENCY TYPE="N">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Aviation Administration</SUBAGY>
                <CFR>14 CFR Part 39</CFR>
                <DEPDOC>[Docket No. FAA-2024-0027; Project Identifier AD-2023-01202-T; Amendment 39-22653; AD 2024-01-02]</DEPDOC>
                <RIN>RIN 2120-AA64</RIN>
                <SUBJECT>Airworthiness Directives; Lockheed Martin Corporation/Lockheed Martin Aeronautics Company Airplanes</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Aviation Administration (FAA), DOT.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule; request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The FAA is adopting a new airworthiness directive (AD) for all Lockheed Martin Corporation/Lockheed Martin Aeronautics Company Model 382, 382B, 382E, 382F, 382G, and 382J airplanes; and Model C-130A, HP-C-130A, EC-130Q, 282-44A-05 (C-130B), C-130B, and C-130H airplanes. This AD was prompted by the determination that certain aft fuselage sloping longerons may have been exposed to excessively hot forming temperatures for excessive amounts of time, which will reduce the mechanical properties of the longerons and affect their static strength. This AD requires, for certain airplanes, a records review to determine if a conductivity check has been performed on the longerons and to determine if the check was measured at least every four inches. This AD also requires, for certain airplanes, an inspection and applicable repairs. This AD also prohibits installation of affected parts under certain conditions. The FAA is issuing this AD to address the unsafe condition on these products.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This AD is effective January 24, 2024.</P>
                    <P>The FAA must receive comments on this AD by February 23, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal:</E>
                         Go to 
                        <E T="03">regulations.gov.</E>
                         Follow the instructions for submitting comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Fax:</E>
                         202-493-2251.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         U.S. Department of Transportation, Docket Operations, M-30, West Building Ground Floor, Room W12-140, 1200 New Jersey Avenue SE, Washington, DC 20590.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery:</E>
                         Deliver to Mail address above between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays.
                    </P>
                    <P>
                        <E T="03">AD Docket:</E>
                         You may examine the AD docket at 
                        <E T="03">regulations.gov</E>
                         by searching for and locating Docket No. FAA-2024-0027; or in person at Docket Operations between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays. The AD docket contains this final rule, any comments received, and other information. The street address for Docket Operations is listed above.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Fred Caplan, Aviation Safety Engineer, FAA, 1701 Columbia Avenue, College Park, GA 30337; telephone 404-474-5507; email 
                        <E T="03">9-ASO-ATLACO-ADs@faa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>The FAA previously issued AD 2023-11-10, Amendment 39-22456 (88 FR 41308, June 26, 2023) (AD 2023-11-10), for all Lockheed Martin Corporation/Lockheed Martin Aeronautics Company Model 382, 382B, 382E, 382F, 382G, and 382J airplanes; and Model C-130A, HP-C-130A, EC-130Q, 282-44A-05 (C-130B), C-130B, and C-130H airplanes. AD 2023-11-10 requires, for certain airplanes, a review of the airplane maintenance records to determine if the left or right aft fuselage sloping longeron, having part number (P/N) 342986-( ), has been replaced on or after December 31, 2012. AD 2023-11-10 also requires a conductivity check on certain aft fuselage sloping longerons and applicable on-condition actions, and prohibits the installation of certain aft fuselage sloping longerons under certain conditions. Lockheed determined that those longerons may have been exposed to excessively hot forming temperatures for excessive amounts of time during manufacturing. Exposure to the higher temperatures and extended time will reduce the mechanical properties of the longerons and affect their static strength. If both aft fuselage sloping longerons are understrength, the structural integrity of the airplane would be reduced below limit load, which could lead to failure of both longerons.</P>
                <P>Lockheed engineering analysis has since identified an increased minimum acceptable hardness (above that required by AD 2023-11-10) necessary to maintain a positive margin of safety from fuselage station (FS) 750 to FS 770. In addition, Lockheed Martin engineering analysis has since identified the vertical flange as the critical location, and this location was not previously tested. As a result, Lockheed Martin Aeronautics Company issued Alert Service Bulletin A382-53-70, dated November 20, 2023, to provide procedures for a conductivity check and hardness test, as applicable, for all affected airplanes, except for Model 382J airplanes.</P>
                <P>Lockheed has advised that related testing has been completed on all Model 382J airplanes (there are currently five total Model 382J airplanes), and that the test results have adequately determined that the aft fuselage sloping longerons meet specifications and the unsafe condition does not currently exist on Model 382J airplanes. Those airplanes are therefore not included in paragraph (g) of this AD. However, the parts installation limitation in paragraph (h)(2) of this AD does apply to the Model 382J airplanes.</P>
                <P>The FAA is issuing this AD to address a defective aft fuselage sloping longeron, which could eventually fail, resulting in reduced structural integrity of the airplane and possible loss of control of the airplane.</P>
                <HD SOURCE="HD1">FAA's Determination</HD>
                <P>The FAA is issuing this AD because the agency has determined the unsafe condition described previously is likely to exist or develop in other products of the same type design.</P>
                <HD SOURCE="HD1">AD Requirements</HD>
                <P>For airplanes (except Model 382J airplanes) on which the left- or right-hand aft fuselage sloping longeron, P/N 342986-( ), was replaced on or after December 31, 2012, and for airplanes (except Model 382J airplanes) on which a review of the airplane maintenance records cannot conclusively determine whether the part has been replaced, this AD requires a review of the airplane maintenance records to determine if a conductivity check has been performed on both left- and right-hand aft fuselage sloping longerons part number 342986-( ), from fuselage station (FS) 750 to FS 770, as specified in Lockheed Martin Aeronautics Company Alert Service Bulletin A382-53-69, dated April 12, 2023, and to determine if the check was measured at least every four inches. This AD also requires, for certain airplanes, an inspection of the airplane and applicable repairs that must be done using a method approved by the Manager, FAA East Certification Branch. The inspection could include a conductivity check, a hardness test, and a verification that results are within certain values.</P>
                <P>This AD also prohibits installation of affected parts under certain conditions.</P>
                <HD SOURCE="HD1">Impact on Intrastate Aviation in Alaska</HD>
                <P>
                    In light of the heavy reliance on aviation for intrastate transportation in Alaska, the FAA fully considered the effects of this AD (including costs to be borne by affected operators) from the 
                    <PRTPAGE P="1031"/>
                    earliest possible stages of AD development. This AD is based on those considerations, and was developed with regard to minimizing the economic impact on operators to the extent possible, consistent with the safety objectives of this AD. In any event, the Federal Aviation Regulations require operators to correct an unsafe condition identified on an airplane to ensure operation of that airplane in an airworthy condition. The FAA has determined in this case that the requirements are necessary and the indirect costs would be outweighed by the safety benefits of the AD.
                </P>
                <HD SOURCE="HD1">Justification for Immediate Adoption and Determination of the Effective Date</HD>
                <P>
                    Section 553(b)(3)(B) of the Administrative Procedure Act (APA) (5 U.S.C. 551 
                    <E T="03">et seq.</E>
                    ) authorizes agencies to dispense with notice and comment procedures for rules when the agency, for “good cause,” finds that those procedures are “impracticable, unnecessary, or contrary to the public interest.” Under this section, an agency, upon finding good cause, may issue a final rule without providing notice and seeking comment prior to issuance. Further, section 553(d) of the APA authorizes agencies to make rules effective in less than thirty days, upon a finding of good cause.
                </P>
                <P>An unsafe condition exists that requires the immediate adoption of this AD without providing an opportunity for public comments prior to adoption. The FAA has found that the risk to the flying public justifies forgoing notice and comment prior to adoption of this rule because numerous understrength aft fuselage sloping longerons have been found on military airplanes of the same type design, and it is likely that understrength longerons are also installed on in-service airplanes. The possibility of both longerons being understrength violates fail-safe design. If both aft fuselage sloping longerons are understrength, the structural integrity of the airplane would be reduced below limit load, which could lead to failure of both longerons and result in loss of the airplane. Accordingly, notice and opportunity for prior public comment are impracticable and contrary to the public interest pursuant to 5 U.S.C. 553(b)(3)(B).</P>
                <P>In addition, the FAA finds that good cause exists pursuant to 5 U.S.C. 553(d) for making this amendment effective in less than 30 days, for the same reasons the FAA found good cause to forgo notice and comment.</P>
                <HD SOURCE="HD1">Comments Invited</HD>
                <P>
                    The FAA invites you to send any written data, views, or arguments about this final rule. Send your comments to an address listed under 
                    <E T="02">ADDRESSES</E>
                    . Include Docket No. FAA-2024-0027 and Project Identifier AD-2023-01202-T at the beginning of your comments. The most helpful comments reference a specific portion of the final rule, explain the reason for any recommended change, and include supporting data. The FAA will consider all comments received by the closing date and may amend this final rule because of those comments.
                </P>
                <P>
                    Except for Confidential Business Information (CBI) as described in the following paragraph, and other information as described in 14 CFR 11.35, the FAA will post all comments received, without change, to 
                    <E T="03">regulations.gov,</E>
                     including any personal information you provide. The agency will also post a report summarizing each substantive verbal contact received about this final rule.
                </P>
                <HD SOURCE="HD1">Confidential Business Information</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 (FOIA) (5 U.S.C. 552), CBI is exempt from public disclosure. If your comments responsive to this AD 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 AD, 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 AD. Submissions containing CBI should be sent to Fred Caplan, Aviation Safety Engineer, FAA, 1701 Columbia Avenue, College Park, GA 30337; telephone 404-474-5507; email 
                    <E T="03">9-ASO-ATLACO-ADs@faa.gov.</E>
                     Any commentary that the FAA receives that is not specifically designated as CBI will be placed in the public docket for this rulemaking.
                </P>
                <HD SOURCE="HD1">Regulatory Flexibility Act</HD>
                <P>The requirements of the Regulatory Flexibility Act (RFA) do not apply when an agency finds good cause pursuant to 5 U.S.C. 553 to adopt a rule without prior notice and comment. Because the FAA has determined that it has good cause to adopt this rule without notice and comment, RFA analysis is not required.</P>
                <HD SOURCE="HD1">Costs of Compliance</HD>
                <P>The FAA estimates that this AD affects 36 airplanes of U.S. registry. The FAA estimates the following costs to comply with this AD:</P>
                <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="xs72,r50,12,xs72,xs72">
                    <TTITLE>Estimated Costs</TTITLE>
                    <BOXHD>
                        <CHED H="1">Action</CHED>
                        <CHED H="1">Labor cost</CHED>
                        <CHED H="1">Parts cost</CHED>
                        <CHED H="1">Cost per product</CHED>
                        <CHED H="1">
                            Cost on U.S.
                            <LI>operators</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Records review</ENT>
                        <ENT>1 work-hour × $85 per hour = $85</ENT>
                        <ENT>$0</ENT>
                        <ENT>$85</ENT>
                        <ENT>$3,060.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Inspection *</ENT>
                        <ENT>Up to 20 work-hours × $85 per hour = Up to $1,700</ENT>
                        <ENT>0</ENT>
                        <ENT>Up to $1,700</ENT>
                        <ENT>Up to $61,200.</ENT>
                    </ROW>
                    <TNOTE>* The inspection could include a conductivity check, a hardness test, and a verification that results are within certain values.</TNOTE>
                </GPOTABLE>
                <P>The FAA has received no definitive data on which to base the cost estimates for the on-condition repair specified in this AD.</P>
                <HD SOURCE="HD1">Authority for This Rulemaking</HD>
                <P>Title 49 of the United States Code specifies the FAA's authority to issue rules on aviation safety. Subtitle I, section 106, describes the authority of the FAA Administrator. Subtitle VII: Aviation Programs describes in more detail the scope of the Agency's authority.</P>
                <P>The FAA is issuing this rulemaking under the authority described in Subtitle VII, Part A, Subpart III, Section 44701: General requirements. Under that section, Congress charges the FAA with promoting safe flight of civil aircraft in air commerce by prescribing regulations for practices, methods, and procedures the Administrator finds necessary for safety in air commerce. This regulation is within the scope of that authority because it addresses an unsafe condition that is likely to exist or develop on products identified in this rulemaking action.</P>
                <HD SOURCE="HD1">Regulatory Findings</HD>
                <P>
                    This AD will not have federalism implications under Executive Order 
                    <PRTPAGE P="1032"/>
                    13132. This AD will not have a substantial direct effect on the States, on the relationship between the national government and the States, or on the distribution of power and responsibilities among the various levels of government.
                </P>
                <P>For the reasons discussed above, I certify that this AD is not a “significant regulatory action” under Executive Order 12866.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 14 CFR Part 39</HD>
                    <P>Air transportation, Aircraft, Aviation safety, Incorporation by reference, Safety.</P>
                </LSTSUB>
                <HD SOURCE="HD1">The Amendment</HD>
                <P>Accordingly, under the authority delegated to me by the Administrator, the FAA amends 14 CFR part 39 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 39—AIRWORTHINESS DIRECTIVES</HD>
                </PART>
                <REGTEXT TITLE="14" PART="39">
                    <AMDPAR>1. The authority citation for part 39 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P> 49 U.S.C. 106(g), 40113, 44701.</P>
                    </AUTH>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 39.13</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="14" PART="39">
                    <AMDPAR>2. The FAA amends § 39.13 by adding the following new airworthiness directive:</AMDPAR>
                    <EXTRACT>
                        <FP SOURCE="FP-2">
                            <E T="04">2024-01-02 Lockheed Martin Corporation/Lockheed Martin Aeronautics Company:</E>
                             Amendment 39-22653; Docket No. FAA-2024-0027; Project Identifier AD-2023-01202-T.
                        </FP>
                        <HD SOURCE="HD1">(a) Effective Date</HD>
                        <P>This airworthiness directive (AD) is effective January 24, 2024.</P>
                        <HD SOURCE="HD1">(b) Affected ADs</HD>
                        <P>This AD affects AD 2023-11-10, Amendment 39-22456 (88 FR 41308, June 26, 2023) (AD 2023-11-10).</P>
                        <HD SOURCE="HD1">(c) Applicability</HD>
                        <P>This AD applies to the airplanes identified in paragraphs (c)(1) through (3) of this AD.</P>
                        <P>(1) All Lockheed Martin Corporation/Lockheed Martin Aeronautics Company Model 382, 382B, 382E, 382F, and 382G airplanes, certificated in any category.</P>
                        <P>(2) All Lockheed Martin Corporation/Lockheed Martin Aeronautics Company Model 382J airplanes, certificated in any category.</P>
                        <P>(3) All airplanes specified in paragraphs (c)(3)(i) through (xi) of this AD, type certificated in the restricted category.</P>
                        <P>(i) LeSEA Model C-130A airplanes (transferred from Central Air Services, Inc.), Type Certificate Data Sheet (TCDS) A34SO, Revision 1.</P>
                        <P>(ii) T.B.M., Inc., Model C-130A airplanes, TCDS A39CE, Revision 3.</P>
                        <P>(iii) Western International Aviation, Inc., Model C-130A airplanes, TCDS A33NM.</P>
                        <P>(iv) USDA Forest Service Model C-130A airplanes, TCDS A15NM, Revision 4.</P>
                        <P>(v) Snow Aviation International, Inc., Model C-130A airplanes, TCDS TQ3CH, Revision 1.</P>
                        <P>(vi) International Air Response (transferred from Rogers Helicopters, Inc., and Heavylift Helicopters Inc.) Model C-130A airplanes, TCDS A31NM, Revision 3.</P>
                        <P>(vii) Heavylift Helicopters, Inc., Model C-130B airplanes, TCDS A35NM, Revision 1.</P>
                        <P>(viii) Hawkins &amp; Powers Aviation, Inc., Model HP-C-130A airplanes, TCDS A30NM, Revision 1.</P>
                        <P>(ix) Coulson Aviation (USA), Inc., Model EC-130Q and C-130H airplanes, TCDS T00019LA, Revision 4.</P>
                        <P>(x) Lockheed-Georgia Company Model 282-44A-05 (C-130B) airplanes, TCDS A5SO.</P>
                        <P>(xi) Surplus Model C-130A airplanes.</P>
                        <HD SOURCE="HD1">(d) Subject</HD>
                        <P>Air Transport Association (ATA) of America Code 53, Fuselage.</P>
                        <HD SOURCE="HD1">(e) Unsafe Condition</HD>
                        <P>
                            This AD was prompted by the determination that certain aft fuselage sloping longerons may have been exposed to excessively hot forming temperatures for excessive amounts of time, which will reduce the mechanical properties of the longerons and affect their static strength. The FAA is issuing this AD to address the possibility of both aft sloping longerons being understrength, which would reduce the structural integrity of the airplane below limit load (
                            <E T="03">i.e.,</E>
                             maximum load to be expected in service) and could lead to failure of both longerons. The unsafe condition, if not addressed, could result loss of the airplane.
                        </P>
                        <HD SOURCE="HD1">(f) Compliance</HD>
                        <P>Comply with this AD within the compliance times specified, unless already done.</P>
                        <HD SOURCE="HD1">(g) Records Review and Applicable Actions</HD>
                        <P>For airplanes identified in paragraphs (c)(1) and (3) of this AD on which the left- or right-hand aft fuselage sloping longeron, P/N 342986-( ), was replaced on or after December 31, 2012, and airplanes identified in paragraphs (c)(1) and (3) of this AD on which a review of the airplane maintenance records cannot conclusively determine whether the part has been replaced: Do the actions specified in both paragraphs (g)(1) and (2) of this AD.</P>
                        <P>(1) Within 35 days after the effective date of this AD, review the airplane maintenance records to determine if a conductivity check has been performed on both left- and right-hand aft fuselage sloping longerons part number 342986-( ), from fuselage station (FS) 750 to FS 770, as specified in Lockheed Martin Aeronautics Company Alert Service Bulletin A382-53-69, dated April 12, 2023, and to determine if the check was measured at least every four inches.</P>
                        <P>(2) Within 90 days after the effective date of this AD, inspect the airplane and do all applicable repairs using a method approved by the Manager, FAA East Certification Branch.</P>
                        <HD SOURCE="HD1">(h) Parts Installation Limitation</HD>
                        <P>(1) For airplanes identified in paragraphs (c)(1) and (3) of this AD: As of the effective date of this AD, no person may install an aft fuselage sloping longeron part number 342986-( ) on any airplane, unless all applicable actions specified in paragraph (g) of this AD have been accomplished. The parts installation limitation required by this paragraph replaces the parts installation limitation required by paragraph (n)(1) of AD 2023-11-10.</P>
                        <P>(2) For airplanes identified in paragraph (c)(2) of this AD: As of the effective date of this AD, no person may install an aft fuselage sloping longeron part number 342986-( ) on any airplane, unless a conductivity check has been performed on the aft fuselage sloping longeron, from fuselage station (FS) 750 to FS 770, using a method approved by the Manager, FAA, East Certification Branch. The parts installation limitation required by this paragraph replaces the parts installation limitation required by paragraph (n)(2) of AD 2023-11-10.</P>
                        <HD SOURCE="HD1">(i) Special Flight Permit</HD>
                        <P>Special flight permits may be issued in accordance with 14 CFR 21.197 and 21.199 to operate the airplane to a location where the actions required by this AD can be performed, but special flight permits may not be issued to operate the airplane after the actions required by this AD have identified an aft fuselage sloping longeron that does not meet the applicable requirements, unless the operator contacts the Manager, East Certification Branch, FAA, for specific limitations that must be followed and complies with those limitations.</P>
                        <HD SOURCE="HD1">(j) Alternative Methods of Compliance (AMOCs)</HD>
                        <P>(1) The Manager, East Certification Branch, FAA, has the authority to approve AMOCs for this AD, if requested using the procedures found in 14 CFR 39.19. In accordance with 14 CFR 39.19, send your request to your principal inspector or responsible Flight Standards Office, as appropriate. If sending information directly to the manager of the certification office, send it to the attention of the person identified in paragraph (k)(1) of this AD.</P>
                        <P>(2) Before using any approved AMOC, notify your appropriate principal inspector, or lacking a principal inspector, the manager of the responsible Flight Standards Office.</P>
                        <HD SOURCE="HD1">(k) Related Information</HD>
                        <P>
                            (1) For more information about this AD, contact Fred Caplan, Aviation Safety Engineer, FAA, 1701 Columbia Avenue, College Park, GA 30337; telephone 404-474-5507; email 
                            <E T="03">9-ASO-ATLACO-ADs@faa.gov.</E>
                        </P>
                        <P>
                            (2) For Lockheed service information identified in this AD that is not incorporated by reference, contact Lockheed Martin Corporation/Lockheed Martin Aeronautics Company, Airworthiness Office, Dept. 6A0M, Zone 0252, Column P-58, 86 S Cobb Drive, Marietta, GA 30063; telephone 770-494-5444; fax 770-494-5445; email 
                            <E T="03">ams.portal@lmco.com.</E>
                             You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 
                            <PRTPAGE P="1033"/>
                            2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
                        </P>
                        <HD SOURCE="HD1">(l) Material Incorporated by Reference</HD>
                        <P>None.</P>
                    </EXTRACT>
                </REGTEXT>
                <SIG>
                    <DATED>Issued on January 4, 2024.</DATED>
                    <NAME>Ross Landes,</NAME>
                    <TITLE>Deputy Director for Regulatory Operations, Compliance &amp; Airworthiness Division, Aircraft Certification Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00300 Filed 1-5-24; 11:15 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-13-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF ENERGY</AGENCY>
                <SUBAGY>Federal Energy Regulatory Commission</SUBAGY>
                <CFR>18 CFR Part 381</CFR>
                <DEPDOC>[Docket No. RM24-2-000]</DEPDOC>
                <SUBJECT>Annual Update of Filing Fees</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Energy Regulatory Commission, Department of Energy.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule; annual update of Commission filing fees.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Commission's regulations, the Commission issues this update of its filing fees. This document provides the yearly update using data in the Commission's Financial System to calculate the new fees. The purpose of updating is to adjust the fees on the basis of the Commission's costs for Fiscal Year 2023.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Effective February 8, 2024.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                         Muhammed Fofana, Office of the Executive Director, Federal Energy Regulatory Commission, 888 1st St. NE, Room 41-02, Washington, DC 20426, 202-502-6046, 
                        <E T="03">Muhammed.Fofana@ferc.gov</E>
                        .
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Introduction</HD>
                <P>1. The Federal Energy Regulatory Commission (Commission) is issuing this document to update filing fees that the Commission assesses for specific services and benefits provided to identifiable beneficiaries. Pursuant to 18 CFR 381.104, the Commission is establishing updated fees on the basis of the Commission's Fiscal Year 2023 costs.</P>
                <HD SOURCE="HD1">II. Information Collection Statement</HD>
                <P>
                    2. OMB approves certain information collection requirements imposed by agency rule.
                    <SU>1</SU>
                    <FTREF/>
                     However, this rule does not contain any new or additional information collection requirements. Therefore, compliance with OMB's regulations is not required.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         5 CFR 1320.12.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">III. Environmental Analysis</HD>
                <P>
                    3. The Commission is required to prepare an Environmental Assessment or an Environmental Impact Statement for any action that may have a significant adverse effect on the human environment.
                    <SU>2</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">Regulations Implementing the National Environmental Policy Act,</E>
                         Order No. 486, 52 FR 47897, FERC Stats. &amp; Regs. ¶ 30,783 (Dec. 17, 1987).
                    </P>
                </FTNT>
                <P>
                    4. Part 380 of the Commission's regulations lists exemptions to the requirement to draft an Environmental Analysis or Environmental Impact Statement. Included is an exemption for procedural, ministerial, or internal administrative actions.
                    <SU>3</SU>
                    <FTREF/>
                     Accordingly, this rulemaking is exempt from the requirement to draft such documents under that provision.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         18 CFR 380.4(a)(1).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">IV. Regulatory Flexibility Act</HD>
                <P>
                    5. The Regulatory Flexibility Act of 1980 (RFA) 
                    <SU>4</SU>
                    <FTREF/>
                     generally requires a description and analysis of final rules that will have a significant economic impact on a substantial number of small entities. This rule concerns an update to filing fees. The Commission certifies that it will not have a significant economic impact upon participants in Commission proceedings. An analysis under the RFA is therefore not required.
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         5 U.S.C. 601-12.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">V. Document Availability</HD>
                <P>
                    6. 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>
                    ).
                </P>
                <P>7. From FERC's Home Page on the internet, this information is available on eLibrary. The full text of this document is available on eLibrary in PDF and Microsoft Word format for viewing, printing, and/or downloading. To access this document in eLibrary, type the docket number excluding the last three digits of this document in the docket number field.</P>
                <P>
                    8. User assistance is available for eLibrary and the FERC's website during normal business hours from FERC Online Support at (202) 502-6652 (toll free at 1-866-208-3676) or email at 
                    <E T="03">ferconlinesupport@ferc.gov,</E>
                     or the Public Reference Room at (202) 502-8371, TTY (202) 502-8659. Email the Public Reference Room at 
                    <E T="03">public.referenceroom@ferc.gov.</E>
                </P>
                <HD SOURCE="HD1">VI. Effective Date</HD>
                <P>9. The Commission is issuing this rule as a final rule without a period for public comment. Under 5 U.S.C. 553(b)(3)(A), notice-and-comment rulemaking procedures are unnecessary for “rules of agency organization, procedure, or practice.” This rule is therefore exempt from notice-and-comment rulemaking procedures, because it concerns the Commission's procedures and practices. In particular, the rule adjusts filing fee amounts. The rule will not significantly affect regulated entities or the general public.</P>
                <P>10. This rule is effective February 8, 2024.</P>
                <P>The new fee schedule is as follows:</P>
                <GPOTABLE COLS="2" OPTS="L2,tp0,p1,8/9,i1" CDEF="s150,12">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1"> </CHED>
                    </BOXHD>
                    <ROW EXPSTB="01" RUL="s">
                        <ENT I="21">
                            <E T="02">Fees Applicable to the Natural Gas Policy Act</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00" RUL="s">
                        <ENT I="01">1. Petitions for rate approval pursuant to 18 CFR 284.123(b)(2). (18 CFR 381.403)</ENT>
                        <ENT>$18,790</ENT>
                    </ROW>
                    <ROW EXPSTB="01" RUL="s">
                        <ENT I="21">
                            <E T="02">Fees Applicable to General Activities</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">1. Petition for issuance of a declaratory order (except under Part I of the Federal Power Act). (18 CFR 381.302(a))</ENT>
                        <ENT>37,760</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">2. Review of a Department of Energy remedial order:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03" O="xl">
                            <E T="03">Amount in controversy:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05">$0-9,999. (18 CFR 381.303(b))</ENT>
                        <ENT>100</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05">$10,000-29,999. (18 CFR 381.303(b))</ENT>
                        <ENT>600</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05">$30,000 or more. (18 CFR 381.303(a))</ENT>
                        <ENT>55,120</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">3. Review of a Department of Energy denial of adjustment:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03" O="xl">
                            <E T="03">Amount in controversy:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="1034"/>
                        <ENT I="05">$0-9,999. (18 CFR 381.304(b))</ENT>
                        <ENT>100</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05">$10,000-29,999. (18 CFR 381.304(b))</ENT>
                        <ENT>600</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05">$30,000 or more. (18 CFR 381.304(a))</ENT>
                        <ENT>28,900</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">4. Written legal interpretations by the Office of General Counsel. (18 CFR 381.305(a))</ENT>
                        <ENT>10,830</ENT>
                    </ROW>
                    <ROW EXPSTB="01" RUL="s">
                        <ENT I="21">
                            <E T="02">Fees Applicable to Natural Gas Pipelines</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00" RUL="s">
                        <ENT I="01">1. Pipeline certificate applications pursuant to 18 CFR 284.224. (18 CFR 381.207(b))</ENT>
                        <ENT>* 1,000</ENT>
                    </ROW>
                    <ROW EXPSTB="01" RUL="s">
                        <ENT I="21">
                            <E T="02">Fees Applicable to Cogenerators and Small Power Producers</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">1. Certification of qualifying status as a small power production facility. (18 CFR 381.505(a))</ENT>
                        <ENT>32,470</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2. Certification of qualifying status as a cogeneration facility. (18 CFR 381.505(a))</ENT>
                        <ENT>36,750</ENT>
                    </ROW>
                    <TNOTE>* This fee has not been changed.</TNOTE>
                </GPOTABLE>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 18 CFR Part 381</HD>
                    <P>Electric power plants, Electric utilities, Natural gas, Reporting and recordkeeping requirements.</P>
                </LSTSUB>
                <SIG>
                    <DATED>Issued: December 27, 2023.</DATED>
                    <NAME>Anton C. Porter,</NAME>
                    <TITLE>Executive Director.</TITLE>
                </SIG>
                <P>In consideration of the foregoing, the Commission amends part 381, chapter I, title 18, Code of Federal Regulations, as set forth below.</P>
                <PART>
                    <HD SOURCE="HED">PART 381—FEES</HD>
                </PART>
                <REGTEXT TITLE="18" PART="381">
                    <AMDPAR>1. The authority citation for part 381 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>15 U.S.C. 717-717w; 16 U.S.C. 791-828c, 2601-2645; 31 U.S.C. 9701; 42 U.S.C. 7101-7352; 49 U.S.C. 60502; 49 App. U.S.C. 1-85.</P>
                    </AUTH>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 381.302</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="18" PART="381">
                    <AMDPAR>2. In § 381.302, paragraph (a) is amended by removing “$35,980” and adding “$37,760” in its place.</AMDPAR>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 381.303</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="18" PART="381">
                    <AMDPAR>3. In § 381.303, paragraph (a) is amended by removing “$52,530” and adding “$55,120” in its place.</AMDPAR>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 381.304</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="18" PART="381">
                    <AMDPAR>4. In § 381.304, paragraph (a) is amended by removing “$27,540” and adding “$28,900” in its place.</AMDPAR>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 381.305</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="18" PART="381">
                    <AMDPAR>5. In § 381.305, paragraph (a) is amended by removing “$10,320” and adding “$10,830” in its place.</AMDPAR>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 381.403</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="18" PART="381">
                    <AMDPAR>6. Section § 381.403 is amended by removing “$17,910” and adding “$18,790” in its place.</AMDPAR>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 381.505</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="18" PART="381">
                    <AMDPAR>7. In § 381.505, paragraph (a) is amended by removing “$30,940” and adding “$32,470” in its place and by removing “$35,030” and adding “$36,750” in its place.</AMDPAR>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00045 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6717-01-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF VETERANS AFFAIRS</AGENCY>
                <CFR>38 CFR Part 17</CFR>
                <RIN>RIN 2900-AR01</RIN>
                <SUBJECT>VA Pilot Program on Graduate Medical Education and Residency</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of Veterans Affairs.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Correcting amendment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        On November 13, 2023, the Department of Veterans Affairs (VA) published a final rule in the 
                        <E T="04">Federal Register</E>
                         to amend its medical regulations to establish a new pilot program on graduate medical education and residency, as required by section 403 of the John S. McCain III, Daniel K. Akaka, and Samuel R. Johnson VA Maintaining Internal Systems and Strengthening Integrated Outside Network Act of 2018. This correction adds the Office of Management and Budget (OMB) control number for the associated information collections.
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This correction is effective January 9, 2024.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Andrea Bennett, Office of Academic Affiliations, Veterans Health Administration, Department of Veterans Affairs, at (202) 368-0324 or 
                        <E T="03">VAMission403Help@va.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    VA published a final rule on November 13, 2023, in the 
                    <E T="04">Federal Register</E>
                     (FR) at 88 FR 77514 to establish the Pilot Program on Graduate Medical Education and Residency in new 38 CFR 17.243 through 17.248. The final rule contained provisions constituting collections of information subject to the Paperwork Reduction Act of 1995 (44 U.S.C. 3507). On December 19, 2023, OMB approved these information collections and assigned OMB control number 2900-0936. This document adds language to 38 CFR 17.243 to reference the approved OMB information collection and OMB control number.
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 38 CFR Part 17</HD>
                    <P>Administrative practice and procedure, Colleges and universities, Education, Government contracts, Health care, Health facilities, Health professions, Indians, Medical and dental schools, Reporting and recordkeeping requirements, Scholarships and fellowships, Schools, Veterans.</P>
                </LSTSUB>
                <SIG>
                    <NAME>Consuela Benjamin,</NAME>
                    <TITLE>Regulations Development Coordinator, Office of Regulation Policy &amp; Management, Office of General Counsel, Department of Veterans Affairs.</TITLE>
                </SIG>
                <HD SOURCE="HD1">Correcting Amendment</HD>
                <P>Accordingly, the Department of Veterans Affairs amends 38 CFR part 17 by making the following correcting amendment:</P>
                <PART>
                    <HD SOURCE="HED">PART 17—MEDICAL</HD>
                </PART>
                <REGTEXT TITLE="38" PART="17">
                    <AMDPAR>1. The authority citation for part 17 continues to read in part as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority: </HD>
                        <P>38 U.S.C. 501, and as noted in specific sections.</P>
                    </AUTH>
                    <STARS/>
                </REGTEXT>
                <REGTEXT TITLE="38" PART="17">
                    <AMDPAR>2. Amend § 17.243 by adding a parenthetical reference at the end of the section to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 17.243</SECTNO>
                        <SUBJECT>Purpose and scope.</SUBJECT>
                        <STARS/>
                        <SECAUTH>(The Office of Management and Budget has approved the information collection provisions in this section under control number 2900-0936).</SECAUTH>
                    </SECTION>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00192 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8320-01-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <PRTPAGE P="1035"/>
                <AGENCY TYPE="N">NATIONAL TRANSPORTATION SAFETY BOARD</AGENCY>
                <CFR>49 CFR Part 831</CFR>
                <DEPDOC>[Docket No.: NTSB-2024-0001]</DEPDOC>
                <RIN>RIN 3147-AA24</RIN>
                <SUBJECT>Civil Monetary Penalty Annual Inflation Adjustment</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Transportation Safety Board (NTSB).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>Pursuant to the Federal Civil Penalties Inflation Adjustment Act Improvements Act of 2015, this final rule provides the 2024 adjustment to the civil penalties that the agency may assess for violations of certain NTSB statutes and regulations.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This final rule is effective on January 9, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        A copy of this final rule, published in the 
                        <E T="04">Federal Register</E>
                         (FR), is available at 
                        <E T="03">https://www.regulations.gov</E>
                         (Docket ID Number NTSB-2024-0001).
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        William Thomas (Tom) McMurry, Jr., General Counsel, (202) 314-6080 or 
                        <E T="03">rulemaking@ntsb.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    The Federal Civil Penalties Inflation Adjustment Act Improvements Act of 2015 (the 2015 Act) requires, in pertinent part, agencies to make an annual adjustment for inflation by January 15th every year. OMB, M-16-06, 
                    <E T="03">Implementation of the Federal Civil Penalties Inflation Adjustment Act Improvements Act of 2015</E>
                     (Feb. 24, 2016). The Office of Management and Budget (OMB) annually publishes guidance on the adjustment multiplier to assist agencies in calculating the mandatory annual adjustments for inflation.
                </P>
                <P>The NTSB's most recent adjustment was for fiscal year (FY) 2023, allowing the agency to impose a civil penalty up to $1,993, effective January 18, 2023 for violations involving 49 U.S.C. 1132 (Civil aircraft accident investigations), 1134(b) (Inspection, testing, preservation, and moving of aircraft and parts), 1134(f)(1) (Autopsies), or 1136(g) (Prohibited actions when providing assistance to families of passengers involved in aircraft accidents). Civil Monetary Penalty Annual Inflation Adjustment, 88 FR 2858 (Jan. 18, 2023).</P>
                <P>
                    OMB has since published updated guidance for FY 2024. OMB, M-24-07, 
                    <E T="03">Implementation of Penalty Inflation Adjustments for 2024, Pursuant to the Federal Civil Penalties Inflation Adjustment Act Improvements Act of 2015</E>
                     (Dec. 19, 2023). Accordingly, this final rule reflects the NTSB's 2024 annual inflation adjustment and updates the maximum civil penalty from $1,993 to $2,058.
                </P>
                <HD SOURCE="HD1">II. The 2024 Annual Adjustment</HD>
                <P>
                    The 2024 annual adjustment is calculated by multiplying the applicable maximum civil penalty amount by the cost-of-living adjustment multiplier, which is based on the Consumer Price Index and rounding to the nearest dollar. OMB, M-23-05, 
                    <E T="03">Implementation of Penalty Inflation Adjustments for 2024, Pursuant to the Federal Civil Penalties Inflation Adjustment Act Improvements Act of 2015</E>
                     (Dec. 19, 2023). For FY 2024, OMB's guidance states that the cost-of-living adjustment multiplier is 1.03241.
                </P>
                <P>Accordingly, multiplying the current penalty of $1,993 by 1.03241 equals $2,057.59313 which rounded up to the nearest dollar equals $2,058. This updated maximum penalty for the upcoming fiscal year applies only to civil penalties assessed after the effective date of this final rule. The next civil penalty adjustment for inflation will be calculated by January 15, 2025.</P>
                <HD SOURCE="HD1">III. Regulatory Analysis</HD>
                <P>
                    The Office of Information and Regulatory Affairs has determined that agency regulations that exclusively implement the annual adjustment are consistent with OMB's annual guidance, and have an annual impact of less than $200 million are generally not significant regulatory actions under Executive Order (E.O.) 12866. OMB, M-23-05, 
                    <E T="03">Implementation of Penalty Inflation Adjustments for 2024, Pursuant to the Federal Civil Penalties Inflation Adjustment Act Improvements Act of 2015</E>
                     (Dec. 19, 2023). Thus, an assessment of its potential costs and benefits under E.O. 12866, 
                    <E T="03">Regulatory Planning and Review</E>
                     and E.O. 13563, 
                    <E T="03">Improving Regulation and Regulatory Review</E>
                     is not required because this final rule is not a “significant regulatory action.” Likewise, this rule does not require analyses under the Unfunded Mandates Reform Act of 1995 because this final rule is not significant.
                </P>
                <P>
                    The Regulatory Flexibility Act (5 U.S.C. 801 
                    <E T="03">et seq.</E>
                    ) requires each agency to review its rulemaking to assess the potential impact on small entities, unless the agency determines a rule is not expected to have a significant economic impact on a substantial number of small entities. In accordance with 5 U.S.C. 605(b), the NTSB certifies that the final rule will not have a significant economic impact on a substantial number of small entities; only those entities that are determined to have violated Federal law and regulations would be affected by the increase in penalties made by this rule.
                </P>
                <P>This final rule complies with all applicable standards in sections 3(a) and 3(b)(2) of E.O. 12988 “Civil Justice Reform,” to minimize litigation, eliminate ambiguity, and reduce burden. In addition, the NTSB has evaluated this rule under E.O. 12630, “Governmental Actions and Interference with Constitutionally Protected Property Rights”; and E.O. 13045, “Protection of Children from Environmental Health Risks and Safety Risks.”</P>
                <P>
                    The NTSB does not anticipate this rule will have a substantial direct effect on state government or will preempt state law. Accordingly, this rule does not have implications for federalism under E.O. 13132, 
                    <E T="03">Federalism.</E>
                </P>
                <P>
                    The NTSB also evaluated this rule under E.O. 13175, 
                    <E T="03">Consultation and Coordination with Indian Tribal Governments.</E>
                     The agency has concluded that this final rule will not have a substantial direct effect on one or more Indian tribes, on the relationship between the Federal Government and Indian tribes, or on the distribution of power and responsibilities between the Federal Government and Indian tribes.
                </P>
                <P>The Paperwork Reduction Act of 1995 is inapplicable because the final rule imposes no new information reporting or recordkeeping necessitating clearance by OMB.</P>
                <P>The NTSB has concluded that this final rule neither violates nor requires further consideration under the aforementioned Executive Orders and acts.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 49 CFR Part 831</HD>
                    <P>Aircraft accidents, Aircraft incidents, Aviation safety, Hazardous materials transportation, Highway safety, Investigations, Marine safety, Pipeline safety, Railroad safety.</P>
                </LSTSUB>
                <P>Accordingly, for the reasons stated in the preamble, the NTSB amends 49 CFR part 831, as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 831—INVESTIGATION PROCEDURES</HD>
                </PART>
                <REGTEXT TITLE="49" PART="831">
                    <AMDPAR>1. The authority citation for part 831 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>49 U.S.C. 1113(f).</P>
                    </AUTH>
                    <EXTRACT>
                        <P>Section 831.15 also issued under Pub. L. 101-410, 104 Stat. 890, amended by Pub. L. 114-74, sec. 701, 129 Stat. 584 (28 U.S.C. 2461 note).</P>
                    </EXTRACT>
                </REGTEXT>
                <SECTION>
                    <PRTPAGE P="1036"/>
                    <SECTNO>§ 831.15</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="49" PART="831">
                    <AMDPAR>2. Amend § 831.15 by removing the dollar amount “$1,993” and add in its place “$2,058”.</AMDPAR>
                </REGTEXT>
                <SIG>
                    <NAME>William T. McMurry, Jr.,</NAME>
                    <TITLE>General Counsel.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00228 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7533-01-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <CFR>50 CFR Part 648</CFR>
                <DEPDOC>[Docket No. 230810-0190; RTID 0648-BL95]</DEPDOC>
                <SUBJECT>Temporary Rule To Extend Gulf of Maine Haddock Emergency Action for the Northeast Multispecies Fishery Management Plan</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>Temporary rule; emergency action.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This temporary rule implements an extension of the Gulf of Maine haddock emergency action for the Northeast multispecies fishery through the remainder of the 2023 fishing year. The emergency action extension is necessary to minimize the potential economic consequences associated with a substantial reduction in the Gulf of Maine haddock annual catch limit compared to recent years for a stock that remains at a very high level of biomass, while still preventing overfishing.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Effective January 9, 2024, through April 30, 2024.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Claire Fitz-Gerald, Fishery Policy Analyst, (978) 281-9255.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    At the New England Fishery Management Council's request, NMFS took emergency action to increase the Gulf of Maine (GOM) haddock acceptable biological catch (ABC). NMFS increased the ABC to 100 percent of the fishing mortality associated with the maximum sustainable yield (F
                    <E T="52">MSY</E>
                    ) (2,515 metric tons (mt)) for fishing year 2023. The emergency measures were included in the final rule for Framework Adjustment 65 to the Northeast Multispecies Fishery Management Plan (FMP) (88 FR 56527; August 18, 2023).
                </P>
                <P>
                    The Council took final action on Framework 65 at its December 2022 meeting. Framework 65 set fishing year 2023 specifications for 16 groundfish stocks, including GOM haddock. The ABC for GOM haddock included in Framework 65 for fishing year 2023 was 1,936 mt. This ABC represented an 83-percent reduction from the fishing year 2022 ABC. The recommendation was based on the results of the 2022 management track assessment for the stock and a 75-percent F
                    <E T="52">MSY</E>
                    , which is consistent with the Council's ABC control rule for stocks that are not in a rebuilding plan.
                </P>
                <P>Following the December 2022 Council meeting, members of the fishing industry started reporting an unanticipated increase in interactions with GOM haddock and raising concerns that the fishery may either meet or exceed its allocation of GOM haddock mid-fishing year due to the low quota, which could result in the closure of the GOM broad stock area to the commercial groundfish fleet or forgoing other fishing opportunities in the GOM in an effort to avoid haddock, both of which would have severely negative impacts for the fishery.</P>
                <P>
                    At its April meeting, in response to fishing industry concerns, the Council voted to request that NMFS implement an emergency action to set the GOM haddock ABC for fishing year 2023 at 90 percent of F
                    <E T="52">MSY</E>
                    , or 2,281 mt, rather than the ABC that was recommended in Framework 65 (1,936 mt, based on 75-percent of F
                    <E T="52">MSY</E>
                    ). On May 2, 2023, the Council sent a letter requesting the emergency action. NMFS reviewed the request and determined that this situation met the criteria specified for emergency rulemaking (62 FR 44421; August 21, 1997). NMFS based this decision on the robust status of the stock, which is estimated to be at 270 percent of its biomass target, recent survey trends indicating that the stock may have experienced another episodic positive recruitment event in 2020, and the temporary nature of the emergency action and any potential extension. NMFS determined that the GOM haddock ABC could be set as high as 100 percent of F
                    <E T="52">MSY</E>
                     (2,515 mt) for fishing year 2023 to minimize economic harm to industry to the extent practicable, while still preventing overfishing. The emergency action implementing the increased fishing year 2023 GOM haddock ABC published on August 18, 2023.
                </P>
                <P>The emergency measures will expire on February 14, 2024, under the Magnuson-Stevens Fishery Conservation and Management Act's initial 180-day limit on the duration of an emergency action. The Magnuson-Stevens Act allows an extension of emergency actions for up to 186 days provided that the public had an opportunity to comment on the emergency action and, for Council-recommended actions, the Council is actively preparing measures to address the emergency. The Council has developed measures to address on an ongoing basis the underlying conditions for the emergency action, and the public had an opportunity to comment on the emergency action as noted below.</P>
                <P>
                    At its December 2023 meeting, the Council took final action on Framework 66 to the groundfish FMP, which intends to set specifications for the 2024 fishing year. Recognizing the increased interactions with a robust GOM haddock stock and the steep reductions from the 2022 fishing year limits, the GOM haddock ABC included in Framework 66 is based on 90 percent of F
                    <E T="52">MSY</E>
                     (2,406 mt). The fishing year 2024 GOM haddock ABC under Framework 65 is 2,038 mt.
                </P>
                <P>
                    Extending the August 18, 2023, emergency action prevents the GOM haddock ABC from reverting to 75-percent of F
                    <E T="52">MSY</E>
                     (1,936 mt) when the emergency action expires. The underlying emergency conditions have not changed. Fishing vessel owners and operators have relied on the emergency action and have changed their fishing behavior in anticipation of the emergency action's continuation through the end of the fishing year. Specifically, fishing vessel operators have avoided GOM haddock and focused on other available stocks in order to conserve GOM haddock allocation for the upcoming spring season. While shifts in GOM haddock interactions are difficult to predict, in both timing and magnitude, this is consistent with increases in fishing effort and GOM haddock catch in past springs. Allowing the emergency action to expire and the ABC to revert to the lower amount approved in Framework 65 mid-year could prevent the fishery from realizing the benefits of increased fishing opportunities for which this action was promulgated. Therefore, we are extending the emergency measures through the end of the 2023 fishing year (April 30, 2024), consistent with the Council's emergency action request and our analysis for fishing year 2023. For the same reasons noted in the August 18, 2023, emergency rule, NMFS has determined that extending the emergency action to maintain the GOM haddock ABC associated with 100-percent of F
                    <E T="52">MSY</E>
                     meets the criteria for emergency action.
                </P>
                <HD SOURCE="HD1">Comments and Responses</HD>
                <P>
                    NMFS received two comments in response to the emergency action. 
                    <PRTPAGE P="1037"/>
                    Neither comment was relevant to this action.
                </P>
                <HD SOURCE="HD1">Classification</HD>
                <P>The NMFS Assistant Administrator has determined that this rule is necessary to respond to an emergency situation and is consistent with the national standards and other provisions of the Magnuson-Stevens Act and other applicable laws.</P>
                <P>The NMFS Assistant Administrator finds good cause under 5 U.S.C. 553(b)(B) that it is contrary to the public interest and impracticable to provide prior notice and opportunity for the public to comment. As more fully explained above, the reasons justifying promulgation of this action on an emergency basis, coupled with the fact that the public has had the opportunity to comment on NMFS' emergency action that this is extending, make solicitation of public comment unnecessary, impractical, and contrary to the public interest. In the interest of receiving public input on this action, the Supplemental Environmental Assessment analyzing this emergency action was made available to the public and the original emergency action solicited public comment.</P>
                <P>For these same reasons stated above, pursuant to 5 U.S.C. 553(d)(3), NMFS finds good cause to waive the full 30-day delay in effectiveness for this action. This action extends the emergency measures currently in place through the remainder of the 2023 fishing year (April 30, 2024). A 30-day delay in effectiveness would be contrary to the public interest because the GOM haddock ABC would temporarily revert to the amount approved in Framework 65, which may disrupt the fishery and lead to confusion for the fishing industry. Because of this, there is good cause to waive the requirement for delayed effectiveness.</P>
                <P>This action is being taken pursuant to the emergency provision of the Magnuson-Stevens Act and is exempt from review by the Office of Management and Budget.</P>
                <P>
                    Because notice and opportunity for comment are not required pursuant to 5 U.S.C. 553 or any other law, the analytical requirements of the Regulatory Flexibility Act (5 U.S.C. 601 
                    <E T="03">et seq.</E>
                    ) are inapplicable. Therefore, a regulatory flexibility analysis is not required and none has been prepared.
                </P>
                <AUTH>
                    <HD SOURCE="HED">Authority: </HD>
                    <P>
                        16 U.S.C. 1801 
                        <E T="03">et seq.</E>
                    </P>
                </AUTH>
                <SIG>
                    <DATED>Dated: January 3, 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-00187 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-22-P</BILCOD>
        </RULE>
    </RULES>
    <VOL>89</VOL>
    <NO>6</NO>
    <DATE>Tuesday, January 9, 2024</DATE>
    <UNITNAME>Proposed Rules</UNITNAME>
    <PRORULES>
        <PRORULE>
            <PREAMB>
                <PRTPAGE P="1038"/>
                <AGENCY TYPE="F">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Aviation Administration</SUBAGY>
                <CFR>14 CFR Part 39</CFR>
                <DEPDOC>[Docket No. FAA-2023-2523; Project Identifier AD-2023-01086-E]</DEPDOC>
                <RIN>RIN 2120-AA64</RIN>
                <SUBJECT>Airworthiness Directives; Pratt &amp; Whitney Turbofan Engines</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Aviation Administration (FAA), 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 adopt a new airworthiness directive (AD) for certain Pratt &amp; Whitney (PW) Model PW1519G, PW1521G, PW1521GA, PW1521G-3, PW1524G, PW1524G-3, PW1525G, PW1525G-3, PW1919G, PW1921G, PW1922G, PW1923G, and PW1923G-A engines. This proposed AD was prompted by an updated analysis of an event involving an International Aero Engines, LLC (IAE LLC) Model PW1127GA-JM engine, which experienced a high-pressure compressor (HPC) 7th-stage integrally bladed rotor (IBR-7) separation that resulted in an engine shutdown and aborted takeoff. This proposed AD would require performing an angled ultrasonic inspection (AUSI) of certain high-pressure turbine (HPT) 1st-stage hubs, HPT 2nd-stage hubs, and HPC 8th-stage disks for cracks and, depending on the results of the inspections, replacing the HPT 1st-stage hubs, HPT 2nd-stage hubs, or HPC 8th-stage disks. This proposed AD would also require accelerated replacement of certain HPC 7th-stage rotors, HPC 8th-stage disks, HPC rear hubs, HPT 1st-stage hubs, HPT 2nd-stage hubs, HPT 1st-stage air seals, HPT 2nd-stage air seals, HPT 1st-stage blade retaining plates, and HPT 2nd-stage blade retaining plates. The FAA is proposing this AD to address the unsafe condition on these products.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The FAA must receive comments on this proposed AD by February 8, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal:</E>
                         Go to 
                        <E T="03">regulations.gov.</E>
                         Follow the instructions for submitting comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Fax:</E>
                         (202) 493-2251.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         U.S. Department of Transportation, Docket Operations, M-30, West Building Ground Floor, Room W12-140, 1200 New Jersey Avenue SE, Washington, DC 20590.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery:</E>
                         Deliver to Mail address above between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays.
                    </P>
                    <P>
                        <E T="03">AD Docket:</E>
                         You may examine the AD docket at 
                        <E T="03">regulations.gov</E>
                         under Docket No. FAA-2023-2523; or in person at Docket Operations between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays. The AD docket contains this NPRM, any comments received, and other information. The street address for Docket Operations is listed above.
                    </P>
                    <P>
                        <E T="03">Material Incorporated by Reference:</E>
                    </P>
                    <P>
                        • For Pratt &amp; Whitney service information identified in this AD, contact International Aero Engines, LLC, 400 Main Street, East Hartford, CT 06118; phone: (860) 565-0140; email: 
                        <E T="03">help24@pw.utc.com;</E>
                         website: 
                        <E T="03">connect.prattwhitney.com.</E>
                    </P>
                    <P>• You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 1200 District Avenue, Burlington, MA 01803. For information on the availability of this material at the FAA, call (817) 222-5110.</P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Carol Nguyen, Aviation Safety Engineer, FAA, 2200 South 216th Street, Des Moines, WA 98198; phone: (781) 238-7655; email: 
                        <E T="03">carol.nguyen@faa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Comments Invited</HD>
                <P>
                    The FAA invites you to send any written relevant data, views, or arguments about this proposal. Send your comments to an address listed under 
                    <E T="02">ADDRESSES</E>
                    . Include “Docket No. FAA-2023-2523; Project Identifier AD-2023-01086-E” at the beginning of your comments. The most helpful comments reference a specific portion of the proposal, explain the reason for any recommended change, and include supporting data. The FAA will consider all comments received by the closing date and may amend this proposal because of those comments.
                </P>
                <P>The FAA has been informed that PW has done some outreach with affected operators regarding the proposed corrective actions for this unsafe condition. As a result, affected operators are already aware of the proposed corrective actions and, in some cases, have already begun planning for replacement of the affected parts. Therefore, the FAA has determined that a 30-day comment period is appropriate given the particular circumstances related to the proposed correction of this unsafe condition.</P>
                <P>
                    Except for Confidential Business Information (CBI) as described in the following paragraph, and other information as described in 14 CFR 11.35, the FAA will post all comments received, without change, to 
                    <E T="03">regulations.gov,</E>
                     including any personal information you provide. The agency will also post a report summarizing each substantive verbal contact received about this NPRM.
                </P>
                <HD SOURCE="HD1">Confidential Business Information</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 (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 Carol Nguyen, Aviation Safety Engineer, FAA, 2200 South 216th Street, Des Moines, WA 98198. Any commentary that the FAA receives which is not specifically designated as CBI will be placed in the public docket for this rulemaking.
                    <PRTPAGE P="1039"/>
                </P>
                <HD SOURCE="HD1">Background</HD>
                <P>On December 24, 2022, an Airbus Model A320neo airplane powered by IAE LLC Model PW1127GA-JM engines, experienced a failure of the HPC IBR-7 that resulted in an engine shutdown and aborted take-off. Following this event, the manufacturer conducted a records review of production and field-returned parts and re-evaluated their engineering analysis methodology. The new analysis found that the failure of the HPC IBR-7 was caused by a nickel powdered metal anomaly, similar in nature to an anomaly previously observed. The analysis also concluded that there is an increased risk of failure for additional nickel powdered metal parts in certain nickel powdered metal production campaigns, and these parts are susceptible to failure much earlier than previously determined. As a result, the FAA is proposing additional AUSIs for certain affected nickel powdered metal parts and removal from service of certain affected nickel powdered metal parts. Certain PW Model PW1519G, PW1521G, PW1521GA, PW1521G-3, PW1524G, PW1524G-3, PW1525G, PW1525G-3, PW1919G, PW1921G, PW1922G, PW1923G, and PW1923G-A engines are among the products affected by this condition. This condition, if not addressed, could result in uncontained disk failure, release of high-energy debris, damage to the engine, damage to the airplane, and possible loss of the airplane.</P>
                <HD SOURCE="HD1">FAA's Determination</HD>
                <P>The FAA is issuing this NPRM after determining that the unsafe condition described previously is likely to exist or develop on other products of the same type design.</P>
                <HD SOURCE="HD1">Related Service Information Under 1 CFR Part 51</HD>
                <P>The FAA reviewed the following service information:</P>
                <P>• PW Alert Service Bulletin (ASB) PW1000G-A-72-00-0196-00A-930A-D, Issue No: 002, dated November 30, 2023, and PW ASB PW1000G-A-72-00-0141-00B-930A-D, Issue No: 002, dated November 30, 2023. This service information specifies a list of affected HPT 1st-stage hubs and HPT 2nd-stage hubs that are identified by serial number (S/N) and installed on certain PW engines; and instructions for performing an AUSI on affected HPT 1st-stage hubs and HPT 2nd-stage hubs.</P>
                <P>• PW ASB PW1000G-A-72-00-0197-00A-930A-D, Issue No: 004, dated November 30, 2023, and PW ASB PW1000G-A-72-00-0142-00B-930A-D, Issue No: 004, dated November 30, 2023. This service information specifies a list of affected HPC 8th-stage disks that are identified by S/N and installed on certain PW engines; and instructions for performing an AUSI on affected HPC 8th-stage disks.</P>
                <P>• PW ASB PW1000G-A-72-00-0204-00A-930A-D Issue No: 001, dated November 30, 2023, and PW ASB PW1000G-A-72-00-0150-00B-930A-D Issue No: 001, dated November 30, 2023, which specifies procedures for performing repetitive AUSIs on affected HPC 8th-stage disks.</P>
                <P>• PW ASB PW1000G-A-72-00-0205-00A-930A-D, Issue No: 001, dated November 30, 2023, and PW ASB PW1000G-A-72-00-0151-00B-930A-D, Issue No: 001, dated November 30, 2023, which specify procedures for performing repetitive AUSIs on affected HPT 1st-stage hubs and HPT 2nd-stage hubs.</P>
                <P>• PW Special Instruction No. 240F-23, dated November 30, 2023, which specifies a list of affected HPT 1st-stage hubs and HPT 2nd-stage hubs that are identified by S/N and installed on certain PW engines.</P>
                <P>
                    This service information is reasonably available because the interested parties have access to it through their normal course of business or by the means identified in 
                    <E T="02">ADDRESSES</E>
                    .
                </P>
                <HD SOURCE="HD1">Proposed AD Requirements in This NPRM</HD>
                <P>This proposed AD would require performing an AUSI of certain HPT 1st-stage hubs, HPT 2nd-stage hubs, and HPC 8th-stage disks for cracks and, depending on the results of the inspections, replacing the HPT 1st-stage hubs, HPT 2nd-stage hubs, or HPC 8th-stage disks. This proposed AD would also require accelerated replacement of certain HPC 7th-stage rotors, HPC 8th-stage disks, HPC rear hubs, HPT 1st-stage air seals, HPT 2nd-stage air seals, HPT 1st-stage hubs, HPT 2nd-stage hubs, HPT 1st-stage blade retaining plates, and HPT 2nd-stage blade retaining plates.</P>
                <HD SOURCE="HD1">Interim Action</HD>
                <P>The FAA considers this AD to be an interim action. This unsafe condition is still under investigation by the manufacturer and, depending on the results of that investigation, the FAA may consider further rulemaking action.</P>
                <HD SOURCE="HD1">Costs of Compliance</HD>
                <P>The FAA estimates that this AD, if adopted as proposed, would affect 430 engines installed on airplanes of U.S. registry. The FAA estimates that 160 engines would need the AUSI of the HPT 1st-stage hub, HPT 2nd-stage hub, and HPC 8th-stage disk; 218 engines would need replacement of the HPT 1st-stage hub; 226 engines would need replacement of the HPT 2nd-stage hub; 231 engines would need replacement of the HPC 7th-stage rotor; 231 engines would need replacement of the HPC 8th-stage disk; 231 engines would need replacement of the HPC rear hub; 231 engines would need replacement of the HPT 1st-stage air seal; 233 engines would need replacement of the HPT 2nd-stage air seal; 232 engines would need replacement of the HPT 1st-stage blade retaining plate; and 231 engines would need replacement of the HPT 2nd-stage blade retaining plate.</P>
                <P>The FAA estimates the following costs to comply with this proposed AD:</P>
                <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s60,r50,14,7,12">
                    <TTITLE>Estimated Costs</TTITLE>
                    <BOXHD>
                        <CHED H="1">Action</CHED>
                        <CHED H="1">Labor cost</CHED>
                        <CHED H="1">
                            Parts cost
                            <LI>(average</LI>
                            <LI>pro-rated cost)</LI>
                        </CHED>
                        <CHED H="1">
                            Cost per
                            <LI>product</LI>
                        </CHED>
                        <CHED H="1">
                            Cost on U.S.
                            <LI>operators</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Perform AUSI of HPT 1st-stage hub, HPT 2nd-stage hub, and HPC 8th-stage disk</ENT>
                        <ENT>60 work-hours × $85 per hour = $5,100</ENT>
                        <ENT>$0</ENT>
                        <ENT>$5,100</ENT>
                        <ENT>$816,000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Replace HPT 1st-stage hub</ENT>
                        <ENT>10 work-hours × $85 per hour = $850</ENT>
                        <ENT>49,500</ENT>
                        <ENT>50,350</ENT>
                        <ENT>10,976,300</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Replace HPT 2nd-stage hub</ENT>
                        <ENT>10 work-hours × $85 per hour = $850</ENT>
                        <ENT>25,500</ENT>
                        <ENT>26,350</ENT>
                        <ENT>5,955,100</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Replace HPC 7th-stage rotor</ENT>
                        <ENT>10 work-hours × $85 per hour = $850</ENT>
                        <ENT>48,000</ENT>
                        <ENT>48,850</ENT>
                        <ENT>11,284,350</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Replace HPC 8th-stage disk</ENT>
                        <ENT>10 work-hours × $85 per hour = $850</ENT>
                        <ENT>35,500</ENT>
                        <ENT>36,350</ENT>
                        <ENT>8,396,850</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Replace HPC rear hub</ENT>
                        <ENT>10 work-hours × $85 per hour = $850</ENT>
                        <ENT>83,000</ENT>
                        <ENT>83,850</ENT>
                        <ENT>19,369,350</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Replace HPT 1st-stage air seal</ENT>
                        <ENT>10 work-hours × $85 per hour = $850</ENT>
                        <ENT>21,000</ENT>
                        <ENT>21,850</ENT>
                        <ENT>5,047,350</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Replace HPT 2nd-stage air seal</ENT>
                        <ENT>10 work-hours × $85 per hour = $850</ENT>
                        <ENT>36,000</ENT>
                        <ENT>36,850</ENT>
                        <ENT>8,586,050</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Replace HPT 1st-stage blade retaining plate</ENT>
                        <ENT>10 work-hours × $85 per hour = $850</ENT>
                        <ENT>34,000</ENT>
                        <ENT>34,850</ENT>
                        <ENT>8,085,200</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="1040"/>
                        <ENT I="01">Replace HPT 2nd-stage blade retaining plate</ENT>
                        <ENT>10 work-hours × $85 per hour = $850</ENT>
                        <ENT>13,000</ENT>
                        <ENT>13,850</ENT>
                        <ENT>3,199,350</ENT>
                    </ROW>
                </GPOTABLE>
                <P>The FAA has included all known costs in its cost estimate. According to the manufacturer, however, some of the costs of this AD may be covered under warranty, thereby reducing the cost impact on affected operators.</P>
                <HD SOURCE="HD1">Authority for This Rulemaking</HD>
                <P>Title 49 of the United States Code specifies the FAA's authority to issue rules on aviation safety. Subtitle I, section 106, describes the authority of the FAA Administrator. Subtitle VII: Aviation Programs, describes in more detail the scope of the Agency's authority.</P>
                <P>The FAA is issuing this rulemaking under the authority described in Subtitle VII, Part A, Subpart III, Section 44701: General requirements. Under that section, Congress charges the FAA with promoting safe flight of civil aircraft in air commerce by prescribing regulations for practices, methods, and procedures the Administrator finds necessary for safety in air commerce. This regulation is within the scope of that authority because it addresses an unsafe condition that is likely to exist or develop on products identified in this rulemaking action.</P>
                <HD SOURCE="HD1">Regulatory Findings</HD>
                <P>The FAA determined that this proposed AD would not have federalism implications under Executive Order 13132. This proposed AD would not have a substantial direct effect on the States, on the relationship between the national government and the States, or on the distribution of power and responsibilities among the various levels of government.</P>
                <P>For the reasons discussed above, I certify this proposed regulation:</P>
                <P>(1) Is not a “significant regulatory action” under Executive Order 12866,</P>
                <P>(2) Would not affect intrastate aviation in Alaska, and</P>
                <P>(3) Would not have a significant economic impact, positive or negative, on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 14 CFR Part 39</HD>
                    <P>Air transportation, Aircraft, Aviation safety, Incorporation by reference, Safety.</P>
                </LSTSUB>
                <HD SOURCE="HD1">The Proposed Amendment</HD>
                <P>Accordingly, under the authority delegated to me by the Administrator, the FAA proposes to amend 14 CFR part 39 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 39—AIRWORTHINESS DIRECTIVES</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 39 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(g), 40113, 44701.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 39.13</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>2. The FAA amends § 39.13 by adding the following new airworthiness directive:</AMDPAR>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        <E T="04">Pratt &amp; Whitney:</E>
                         Docket No. FAA-2023-2523; Project Identifier AD-2023-01086-E.
                    </FP>
                    <HD SOURCE="HD1">(a) Comments Due Date</HD>
                    <P>The FAA must receive comments on this airworthiness directive (AD) by February 8, 2024.</P>
                    <HD SOURCE="HD1">(b) Affected ADs</HD>
                    <P>None.</P>
                    <HD SOURCE="HD1">(c) Applicability</HD>
                    <P>Pratt &amp; Whitney (PW) Model PW1519G, PW1521G, PW1521GA, PW1521G-3, PW1524G, PW1524G-3, PW1525G, PW1525G-3, PW1919G, PW1921G, PW1922G, PW1923G, and PW1923G-A engines.</P>
                    <HD SOURCE="HD1">(d) Subject</HD>
                    <P>Joint Aircraft System Component (JASC) Code 7230, Turbine Engine Compressor Section; 7250, Turbine Section.</P>
                    <HD SOURCE="HD1">(e) Unsafe Condition</HD>
                    <P>This AD was prompted by an updated analysis of an event involving an International Aero Engines, LLC Model PW1127GA-JM engine, which experienced a high-pressure compressor (HPC) 7th-stage integrally bladed rotor separation that resulted in an engine shutdown and aborted takeoff. The FAA is issuing this AD to prevent failure of the high-pressure turbine (HPT) 1st-stage hub, HPT 2nd-stage hub, and HPC 8th-stage disk. The unsafe condition, if not addressed, could result in uncontained hub failure, release of high-energy debris, damage to the engine, damage to the airplane, and possible loss of the airplane.</P>
                    <HD SOURCE="HD1">(f) Compliance</HD>
                    <P>Comply with this AD within the compliance times specified, unless already done.</P>
                    <HD SOURCE="HD1">(g) Required Actions</HD>
                    <P>(1) For PW1500G engines with an installed HPC 8th-stage disk having part number (P/N) 30G7208, at the next HPC engine shop visit, except as required by paragraph (g)(3) of this AD, perform an angled ultrasonic inspection (AUSI) of the affected HPC 8th-stage disk for cracks in accordance with the Accomplishment Instructions, paragraph 8., of PW Alert Service Bulletin (ASB) PW1000G-A-72-00-0197-00A-930A-D, Issue No: 004, dated November 30, 2023.</P>
                    <P>(2) For PW1500G engines with an installed HPT 1st-stage hub having P/N 30G8501 or an installed HPT 2nd-stage hub having P/N 30G7202, at the next engine shop visit, except as required by paragraph (g)(3) of this AD, perform an AUSI of the affected HPT 1st-stage hub or HPT 2nd-stage hub, as applicable, for cracks in accordance with the Accomplishment Instructions, paragraph 8.A. or 8.B., of PW ASB PW1000G-A-72-00-0196-00A-930A-D, Issue No: 002, dated November 30, 2023.</P>
                    <P>(3) For PW1500G engines with an installed part, P/N and serial number (S/N) listed in Table 1 to paragraph (g)(3) of this AD with no AUSI performed prior to the effective date of this AD, within the applicable compliance time listed in Table 1 to paragraph (g)(3) of this AD or within 100 flight cycles (FCs) after the effective date of this AD, whichever occurs later, perform an AUSI of the affected part for cracks in accordance with the applicable service bulletin listed in Table 1 to paragraph (g)(3) of this AD.</P>
                    <GPOTABLE COLS="4" OPTS="L2,p7,7/8,i1" CDEF="s30,r60,r50,r75">
                        <TTITLE>
                            Table 1 to Paragraph 
                            <E T="01">(g)(3)</E>
                            —AUSI Compliance Times
                        </TTITLE>
                        <BOXHD>
                            <CHED H="1">Part</CHED>
                            <CHED H="1">Applicable S/N listing</CHED>
                            <CHED H="1">Compliance time</CHED>
                            <CHED H="1">
                                Applicable service bulletin
                                <LI>(see paragraph (m)(2) of this AD)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">
                                HPC 8th-stage disk
                                <LI O="xl">P/N 30G7208</LI>
                            </ENT>
                            <ENT>Table 1 of PW ASB PW1000G-A-72-00-0197-00A-930A-D</ENT>
                            <ENT>Next HPC engine shop visit not to exceed 10,000 part cycles since new (CSN)</ENT>
                            <ENT>Accomplishment Instructions, paragraph 8., of PW ASB PW1000G-A-72-00-0197-00A-930A-D.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                HPT 1st-stage hub
                                <LI O="xl">P/N 30G8501</LI>
                            </ENT>
                            <ENT>Table 2 of PW ASB PW1000G-A-72-00-0196-00A-930A-D</ENT>
                            <ENT>Next engine shop visit not to exceed 5,000 part CSN</ENT>
                            <ENT>Accomplishment Instructions, paragraph 8.A. of PW ASB PW1000G-A-72-00-0196-00A-930A-D</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="1041"/>
                            <ENT I="01">
                                HPT 2nd-stage hub
                                <LI O="xl">P/N 30G7202</LI>
                            </ENT>
                            <ENT>Table 3 of PW ASB PW1000G-A-72-00-0196-00A-930A-D</ENT>
                            <ENT>Next engine shop visit not to exceed 5,000 part CSN</ENT>
                            <ENT>Accomplishment Instructions, paragraph 8.B, of PW ASB PW1000G-A-72-00-0196-00A-930A-D.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                HPT 1st-stage hub
                                <LI O="xl">P/N 30G8501</LI>
                            </ENT>
                            <ENT>Table 4 of PW ASB PW1000G-A-72-00-0196-00A-930A-D</ENT>
                            <ENT>Next engine shop visit not to exceed 4,000 part CSN</ENT>
                            <ENT>Accomplishment Instructions, paragraph 8.A, of PW ASB PW1000G-A-72-00-0196-00A-930A-D.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                HPT 2nd-stage hub
                                <LI O="xl">P/N 30G7202</LI>
                            </ENT>
                            <ENT>Table 5 of PW ASB PW1000G-A-72-00-0196-00A-930A-D</ENT>
                            <ENT>Next engine shop visit not to exceed 4,000 part CSN</ENT>
                            <ENT>Accomplishment Instructions, paragraph 8.B., of PW ASB PW1000G-A-72-00-0196-00A-930A-D.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>(4) Thereafter at each piece-part exposure of the affected part for PW1500G engines with an installed HPC 8th-stage disk having P/N 30G7208, an installed HPT 1st-stage hub having P/N 30G8501, or an installed HPT 2nd-stage hub having P/N 30G7202, do the following:</P>
                    <P>(i) Perform an AUSI of the affected HPC 8th-stage disk for cracks in accordance with the Accomplishment Instructions, paragraph 5.B., PW ASB PW1000G-A-72-00-0204-00A-930A-D, Issue No: 001, dated November 30, 2023.</P>
                    <P>(ii) Perform an AUSI of the affected HPT 1st-stage hub and HPT 2nd-stage hub, as applicable, for cracks in accordance with the Accomplishment Instructions, paragraph 7.A. or 7.B., of PW ASB PW1000G-A-72-00-0205-00A-930A-D, Issue No: 001, dated November 30, 2023.</P>
                    <P>(5) For PW1900G engines with an installed HPC 8th-stage disk having P/N 30G7208, at the next HPC engine shop visit, except as required by paragraph (g)(7) of this AD, perform an AUSI of the affected HPC 8th-stage disk for cracks in accordance with the Accomplishment Instructions, paragraph 8., of Pratt &amp; Whitney PW ASB PW1000G-A-72-00-0142-00B-930A-D, Issue No: 004, dated November 30, 2023.</P>
                    <P>(6) For PW1900G engines with an installed HPT 1st-stage hub having P/N 30G8501 or an installed HPT 2nd-stage hub having P/N 30G7202, at the next engine shop visit, except as required by paragraph (g)(7) of this AD, perform an AUSI of the affected HPT 1st-stage hub and HPT 2nd-stage hub, as applicable, for cracks in accordance with the Accomplishment Instructions, paragraph 8.A. or 8.B., of PW ASB PW1000G-A-72-00-0141-00B-930A-D, Issue No: 002, dated November 30, 2023.</P>
                    <P>(7) For PW1900G engines with an installed part, P/N and S/N listed in Table 2 to paragraph (g)(7) of this AD, with no AUSI performed prior to the effective date of this AD, within the compliance time listed in Table 2 to paragraph (g)(7) of this AD or within 100 FCs after the effective date of this AD, whichever occurs later, perform an AUSI of the affected parts for cracks in accordance with the applicable service bulletin listed in Table 2 to paragraph (g)(7) of this AD.</P>
                    <GPOTABLE COLS="4" OPTS="L2,p7,7/8,i1" CDEF="s30,r60,r50,r75">
                        <TTITLE>
                            Table 2 to Paragraph 
                            <E T="01">(g)(7)</E>
                            —AUSI Compliance Times
                        </TTITLE>
                        <BOXHD>
                            <CHED H="1">Part</CHED>
                            <CHED H="1">Table S/N is listed in</CHED>
                            <CHED H="1">Compliance time</CHED>
                            <CHED H="1">
                                Applicable service bulletin
                                <LI>(see paragraph (m)(2) of this AD)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">HPC 8th-stage disk having P/N 30G7208</ENT>
                            <ENT>Table 1 of PW ASB PW1000G-A-72-00-0142-00B-930A-D</ENT>
                            <ENT>Next HPC engine shop visit not to exceed 10,000 part CSN</ENT>
                            <ENT>Accomplishment Instructions, paragraph 8., of PW ASB PW1000G-A-72-00-0142-00B-930A-D.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">HPT 1st-stage hub having P/N 30G8501</ENT>
                            <ENT>Table 2 of PW ASB PW1000G-A-72-00-0141-00B-930A-D</ENT>
                            <ENT>Next engine shop visit not to exceed 5,000 part CSN</ENT>
                            <ENT>Accomplishment Instructions, paragraph 8.A., of PW ASB PW1000G-A-72-00-0141-00B-930A-D.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">HPT 2nd-stage hub having P/N 30G7202</ENT>
                            <ENT>Table 3 of PW ASB PW1000G-A-72-00-0141-00B-930A-D</ENT>
                            <ENT>Next engine shop visit not to exceed 5,000 part CSN</ENT>
                            <ENT>Accomplishment Instructions, paragraph 8.B, of PW ASB PW1000G-A-72-00-0141-00B-930A-D.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">HPT 1st-stage hub having P/N 30G8501</ENT>
                            <ENT>Table 4 of PW ASB PW1000G-A-72-00-0141-00B-930A-D</ENT>
                            <ENT>Next engine shop visit not to exceed 4,000 part CSN</ENT>
                            <ENT>Accomplishment Instructions, paragraph 8.A., of PW ASB PW1000G-A-72-00-0141-00B-930A-D.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">HPT 2nd-stage hub having P/N 30G7202</ENT>
                            <ENT>Table 5 of PW ASB PW1000G-A-72-00-0141-00B-930A-D</ENT>
                            <ENT>Next engine shop visit not to exceed 4,000 part CSN</ENT>
                            <ENT>Accomplishment Instructions, paragraph 8.B., of PW ASB PW1000G-A-72-00-0141-00B-930A-D.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>(8) Thereafter at each piece-part exposure of the affected part for PW1900G engines with an installed HPC 8th-stage disk having P/N 30G7208, or an installed HPT 1st-stage hub having P/N 30G8501, or an installed HPT 2nd-stage hub having P/N 30G7202, do the following:</P>
                    <P>(i) Perform an AUSI of the affected HPC 8th-stage disk for cracks in accordance with the Accomplishment Instructions, paragraph 5.B., of PW ASB PW1000G-A-72-00-0150-00B-930A-D, Issue No: 001, dated November 30, 2023.</P>
                    <P>(ii) Perform an AUSI of the affected HPT 1st-stage hub and HPT 2nd-stage hub, as applicable, for cracks in accordance with the Accomplishment Instructions, paragraph 7.A. or 7.B., of PW ASB PW1000G-A-72-00-0151-00B-930A-D, Issue No: 001, dated November 30, 2023.</P>
                    <P>(9) If any crack is found during the inspections required by paragraph (g) of this AD, before further flight, remove the affected part from service and replace with a part eligible for installation.</P>
                    <P>(10) For engines with an installed part and P/N listed in Table 3 to paragraph (g)(10) of this AD having 3,300 CSN or less on the effective date of this AD, before the part accumulates 4,000 CSN or at the next engine shop visit after the effective date of this AD, whichever occurs first, remove the part from service and replace with a part eligible for installation.</P>
                    <GPOTABLE COLS="2" OPTS="L2,nj,p7,7/8,i1" CDEF="s50,8">
                        <TTITLE>
                            Table 3 to Paragraph 
                            <E T="01">(g)(10)</E>
                            —Part Numbers
                        </TTITLE>
                        <BOXHD>
                            <CHED H="1">Part name</CHED>
                            <CHED H="1">P/N</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">HPC 7th-stage rotor</ENT>
                            <ENT>30G3307</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">HPC 8th-stage disk</ENT>
                            <ENT>30G3248</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">HPC rear hub</ENT>
                            <ENT>30G2902</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">HPT 1st-stage hub</ENT>
                            <ENT>30G5701</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">HPT 2nd-stage hub</ENT>
                            <ENT>30G5002</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">HPT 1st-stage air seal</ENT>
                            <ENT>30G3132</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">HPT 2nd-stage air seal</ENT>
                            <ENT>30G3451</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">HPT 1st-stage blade retaining plate</ENT>
                            <ENT>30G1692</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">HPT 2nd-stage blade retaining plate</ENT>
                            <ENT>30G1698</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>(11) For engines with an installed part and P/N listed in Table 3 to paragraph (g)(10) of this AD having more than 3,300 CSN on the effective date of this AD, at the next engine shop visit or within 700 FCs after the effective date of this AD, whichever occurs first, remove the part from service and replace it with a part eligible for installation.</P>
                    <P>(12) For engines with an installed HPT 1st-stage hub having P/N 30G8501 or an installed HPT 2nd-stage hub having P/N 30G7202 and an S/N listed in Table 1 of PW Special Instruction (SI) No. 240F-23, dated November 30, 2023, within 100 FCs from the effective date of this AD, remove the hub from service and replace it with a part eligible for installation.</P>
                    <P>(13) If an affected part has accumulated 100 FCs or less since the last AUSI, reinspection is not required provided that the part was not damaged during removal from the engine.</P>
                    <HD SOURCE="HD1">(h) Installation Prohibition</HD>
                    <P>After the effective date of this AD, do not install an HPT 1st-stage hub having P/N 30G8501 or an HPT 2nd-stage hub having P/N 30G7202 and an S/N listed in Table 1 of PW SI No. 240F-23, dated November 30, 2023, in any engine.</P>
                    <HD SOURCE="HD1">(i) Definitions</HD>
                    <P>
                        (1) For the purposes of this AD, “PW1500G” engines are PW Model PW1519G, PW1521G, PW1521GA, PW1521G-3, PW1524G, PW1524G-3, PW1525G, and PW1525G-3 engines.
                        <PRTPAGE P="1042"/>
                    </P>
                    <P>(2) For the purposes of this AD, “PW1900G” engines are PW Model PW1919G, PW1921G, PW1922G, PW1923G, and PW1923G-A engines.</P>
                    <P>(3) For the purposes of this AD, a “part eligible for installation” is:</P>
                    <P>(i) Any HPC 7th-stage rotor, P/N 30G5307 or later approved P/N.</P>
                    <P>(ii) Any HPC 8th-stage disk, P/N 30G7208, that has passed the AUSI required by paragraph (g) of this AD or later approvedP/N.</P>
                    <P>(iii) Any HPC rear hub, P/N 30G7308 or later approved P/N.</P>
                    <P>(iv) Any HPT 1st-stage hub, P/N 30G8501, that has passed the AUSI required by paragraph (g) of this AD or later approvedP/N.</P>
                    <P>(v) Any HPT 2nd-stage hub, P/N 30G7202, that has passed the AUSI required by paragraph (g) of this AD or later approvedP/N.</P>
                    <P>(vi) Any HPT 1st-stage air seal, P/N 30G5195 or later approved P/N.</P>
                    <P>(vii) Any HPT 2nd-stage air seal, P/N 30G5196 or later approved P/N.</P>
                    <P>(viii) Any HPT 1st-stage blade retaining plate, P/N 30G5193 or later approved P/N.</P>
                    <P>(ix) Any HPT 2nd-stage blade retaining plate, P/N 30G5194 or later approved P/N.</P>
                    <P>(4) For the purposes of this AD, a “piece-part exposure” is when the part is disassembled from the rotor assembly.</P>
                    <P>(5) For the purposes of this AD, an “engine shop visit” is the induction of an engine into the shop for maintenance involving the separation of pairs of major mating engine flanges, except for the following situations, which do not constitute an engine shop visit.</P>
                    <P>(i) The separation of engine flanges solely for the purposes of transportation without subsequent engine maintenance.</P>
                    <P>(ii) Fan case maintenance or replacement.</P>
                    <P>(6) For the purposes of this AD, an “HPC engine shop visit” is when the HPC rotor assembly is removed from the engine.</P>
                    <HD SOURCE="HD1">(j) Credit for Previous Actions</HD>
                    <P>This paragraph provides credit for the initial AUSI of the HPC 8th-stage disk, HPT 1st-stage hub and HPT 2nd-stage hub specified in paragraph (g)(1), (2), (4) and (5) of this AD, if the initial AUSI was performed before the effective date of this AD using the following service information;</P>
                    <P>(1) PW ASB PW1000G-A-72-00-0196-00A-930A-D, Issue No: 001, dated March 16, 2023; or</P>
                    <P>(2) PW ASB PW1000G-A-72-00-0197-00A-930A-D, Issue No: 001, dated March 22, 2023; or</P>
                    <P>(3) PW ASB PW1000G-A-72-00-0197-00A-930A-D, Issue No: 002, dated June 19, 2023; or</P>
                    <P>(4) PW ASB PW1000G-A-72-00-0197-00A-930A-D, Issue No: 003, dated August 14, 2023; or</P>
                    <P>(5) PW ASB PW1000G-A-72-00-0141-00B-930A-D, Issue No: 001, dated March 16, 2023; or</P>
                    <P>(6) PW ASB PW1000G-A-72-00-0142-00B-930A-D, Issue No: 001, dated March 22, 2023; or</P>
                    <P>(7) PW ASB PW1000G-A-72-00-0142-00B-930A-D, Issue No: 002, dated June 19, 2023.; or</P>
                    <P>(8) PW ASB PW1000G-A-72-00-0142-00B-930A-D, Issue No: 003, dated August 14, 2023.</P>
                    <HD SOURCE="HD1">(k) Alternative Methods of Compliance (AMOCs)</HD>
                    <P>(1) The Manager, AIR-520 Continued Operational Safety Branch, FAA, has the authority to approve AMOCs for this AD, if requested using the procedures found in 14 CFR 39.19. In accordance with 14 CFR 39.19, send your request to your principal inspector or local Flight Standards District Office, as appropriate. If sending information directly to the manager of AIR-520 Continued Operational Safety Branch, send it to the attention of the person identified in paragraph (l)(1) of this AD.</P>
                    <P>(2) Before using any approved AMOC, notify your appropriate principal inspector, or lacking a principal inspector, the manager of the local flight standards district office/certificate holding district office.</P>
                    <HD SOURCE="HD1">(l) Additional Information</HD>
                    <P>
                        (1) For more information about this AD, contact Carol Nguyen, Aviation Safety Engineer, FAA, 2200 South 216th Street, Des Moines, WA 98198; phone: (781) 238-7655; email: 
                        <E T="03">carol.nguyen@faa.gov.</E>
                    </P>
                    <P>(2) Service information identified in this AD that is not incorporated by reference is available at the addresses specified in paragraphs (m)(3) and (4) of this AD.</P>
                    <HD SOURCE="HD1">(m) Material Incorporated by Reference</HD>
                    <P>(1) The Director of the Federal Register approved the incorporation by reference (IBR) of the service information listed in this paragraph under 5 U.S.C. 552(a) and 1 CFR part 51.</P>
                    <P>(2) You must use this service information as applicable to do the actions required by this AD, unless the AD specifies otherwise.</P>
                    <P>(i) Pratt &amp; Whitney (PW) Alert Service Bulletin (ASB) PW1000G-A-72-00-0141-00B-930A-D, Issue No: 002, dated November 30, 2023.</P>
                    <P>(ii) PW ASB PW1000G-A-72-00-0142-00B-930A-D, Issue No: 004, dated November 30, 2023.</P>
                    <P>(iii) PW ASB PW1000G-A-72-00-0150-00B-930A-D Issue No:001, dated November 30, 2023.</P>
                    <P>(iv) PW ASB PW1000G-A-72-00-0151-00B-930A-D, Issue No: 001, dated November 30, 2023.</P>
                    <P>(v) PW ASB PW1000G-A-72-00-0196-00A-930A-D, Issue No: 002, dated November 30, 2023.</P>
                    <P>(vi) PW ASB PW1000G-A-72-00-0197-00A-930A-D, Issue No: 004, dated November 30, 2023.</P>
                    <P>(vii) PW ASB PW1000G-A-72-00-0204-00A-930A-D Issue No:001, dated November 30, 2023.</P>
                    <P>(viii) PW ASB PW1000G-A-72-00-0205-00A-930A-D, Issue No: 001, dated November 30, 2023.</P>
                    <P>(ix) PW Special Instruction No. 240F-23, dated November 30, 2023.</P>
                    <P>
                        (3) For PW service information identified in this AD, contact International Aero Engines, LLC, 400 Main Street, East Hartford, CT 06118; phone: (860) 565-0140; email: 
                        <E T="03">help24@pw.utc.com;</E>
                         website: 
                        <E T="03">connect.prattwhitney.com.</E>
                    </P>
                    <P>(4) You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 1200 District Avenue, Burlington, MA 01803. For information on the availability of this material at the FAA, call (817) 222-5110.</P>
                    <P>
                        (5) You may view this material at the National Archives and Records Administration (NARA). For information on the availability of this material at NARA, visit: 
                        <E T="03">www.archives.gov/federal-register/cfr/ibr-locations</E>
                         or email 
                        <E T="03">fr.inspection@nara.gov.</E>
                    </P>
                </EXTRACT>
                <SIG>
                    <DATED>Issued on December 27, 2023.</DATED>
                    <NAME>Caitlin Locke,</NAME>
                    <TITLE>Director, Compliance &amp; Airworthiness Division, Aircraft Certification Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00309 Filed 1-5-24; 4:15 pm]</FRDOC>
            <BILCOD>BILLING CODE 4910-13-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF THE TREASURY</AGENCY>
                <SUBAGY>Internal Revenue Service</SUBAGY>
                <CFR>26 CFR Part 53</CFR>
                <DEPDOC>[REG-142338-07]</DEPDOC>
                <RIN>RIN 1545-BI33</RIN>
                <SUBJECT>Taxes on Taxable Distributions From Donor Advised Funds Under Section 4966</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Internal Revenue Service (IRS), Treasury</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of proposed rulemaking; extension of comment period.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        This document extends the period to submit comments or to request a public hearing for a notice of proposed rulemaking (REG-142338-07) that was published in the 
                        <E T="04">Federal Register</E>
                         on Tuesday, November 14, 2023. The proposed regulations relate to excise taxes on taxable distributions made by a sponsoring organization from a donor advised fund, and on the agreement of certain fund managers to the making of such distributions.
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The period to submit written or electronic comments for the notice of proposed rulemaking published on November 14, 2023 (88 FR 77922) or to request a public hearing is extended from January 16, 2024, to February 15, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Commenters are strongly encouraged to submit public comments electronically. Submit electronic submissions via the Federal eRulemaking Portal at 
                        <E T="03">www.regulations.gov</E>
                         (indicate IRS and REG-142338-07) by following the online instructions for submitting comments. Once submitted to the Federal eRulemaking Portal, comments cannot be edited or withdrawn. The Department of the Treasury (Treasury 
                        <PRTPAGE P="1043"/>
                        Department) and the IRS will publish any comments submitted electronically or on paper to the public docket. Send paper submissions to: CC:PA:01:PR (REG-142338-07), Room 5203, Internal Revenue Service, P.O. Box 7604, Ben Franklin Station, Washington, DC 20044.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Concerning the proposed regulations Christopher A. Hyde of the Office of Associate Chief Counsel (Employee Benefits, Exempt Organizations, and Employment Taxes) at (202) 317-5800 (not a toll-free number). Concerning submissions of comments and requests for a public hearing, Vivian Hayes at 
                        <E T="03">publichearings@irs.gov</E>
                         (preferred) or at (202) 317-6901 (not a toll-free number).
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION: </HD>
                <P>
                    A notice of proposed rulemaking and request for comments that appeared in the 
                    <E T="04">Federal Register</E>
                     on Tuesday, November 14, 2023 (88 FR 77922) announced that written or electronic comments must be received by January 16, 2024. In response to requests from multiple commenters, the due date to receive comments or request a public hearing has been extended to Thursday, February 15, 2024.
                </P>
                <SIG>
                    <NAME>Oluwafunmilayo A. Taylor,</NAME>
                    <TITLE>Section Chief, Publications and Regulations, Associate Chief Counsel (Procedure &amp; Administration).</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00260 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4830-01-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF DEFENSE</AGENCY>
                <AGENCY TYPE="O">GENERAL SERVICES ADMINISTRATION</AGENCY>
                <AGENCY TYPE="O">NATIONAL AERONAUTICS AND SPACE ADMINISTRATION</AGENCY>
                <CFR>48 CFR Parts 2, 3, 9, 22, 23, 25, 33, and 52</CFR>
                <DEPDOC>[FAR Case 2019-015; Docket No. FAR-2019-0015; Sequence No. 1]</DEPDOC>
                <RIN>RIN 9000-AN98</RIN>
                <SUBJECT>Federal Acquisition Regulation: Improving Consistency Between Procurement and Nonprocurement Procedures on Suspension and Debarment</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of Defense (DoD), General Services Administration (GSA), and National Aeronautics and Space Administration (NASA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Proposed rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>DoD, GSA, and NASA are proposing to amend the Federal Acquisition Regulation (FAR) to improve consistency between the procurement and nonprocurement procedures on suspension and debarment, based on the recommendations of the Interagency Suspension and Debarment Committee.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Interested parties should submit written comments to the Regulatory Secretariat Division at the address shown below on or before March 11, 2024 to be considered in the formation of the final rule.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Submit comments in response to FAR Case 2019-015 to the Federal eRulemaking portal at 
                        <E T="03">https://www.regulations.gov</E>
                         by searching for “FAR Case 2019-015”. Select the link “Comment Now” that corresponds with “FAR Case 2019-015”. Follow the instructions provided on the “Comment Now” screen. Please include your name, company name (if any), and “FAR Case 2019-015” on your attached document. If your comment cannot be submitted using 
                        <E T="03">https://www.regulations.gov,</E>
                         call or email the point of contact in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section of this document for alternate instructions.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         Please submit comments only and cite “FAR Case 2019-015” in all correspondence related to this case. Comments received generally will be posted without change to 
                        <E T="03">https://www.regulations.gov,</E>
                         including any personal and/or business confidential information provided. Public comments may be submitted as an individual, as an organization, or anonymously (see frequently asked questions at 
                        <E T="03">https://www.regulations.gov/faq</E>
                        ). To confirm receipt of your comment(s), please check 
                        <E T="03">https://www.regulations.gov,</E>
                         approximately two to three days after submission to verify posting.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For clarification of content, contact Ms. Zenaida Delgado, Procurement Analyst, at 202-969-7207 or by email at 
                        <E T="03">zenaida.delgado@gsa.gov.</E>
                         For information pertaining to status, publication schedules, or alternate instructions for submitting comments if https: 
                        <E T="03">www.regulations.gov</E>
                         cannot be used, contact the Regulatory Secretariat Division at 202-501-4755 or 
                        <E T="03">GSARegSec@gsa.gov.</E>
                         Please cite FAR Case 2019-015.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    The Government uses suspension and debarment procedures to protect its business interests. These procedures give Federal officials a means to bar parties from participation in certain transactions, while affording those parties due process. Over time, two separate suspension and debarment regulatory systems have evolved: (1) the FAR system within the Federal Acquisition Regulation for procurement matters; and (2) the Nonprocurement system within the Nonprocurement Common Rule (NCR), which covers grants, cooperative agreements, contracts of assistance, loans, and loan guarantees. The regulations for the FAR system are in subpart 9.4, Debarment, Suspension, and Ineligibility, of Title 48 in the Code of Federal Regulations (CFR). The Nonprocurement system is in Title 2, Part 180 of the CFR and directs Federal agencies to issue their own implementing regulations consistent with the NCR. Executive Order 12689, “Debarment and Suspension”, published in the 
                    <E T="04">Federal Register</E>
                     at 54 FR 34131 on August 18, 1989, directed that suspension or debarment under either system has a reciprocal effect, thereby excluding parties that have been excluded under either system from both new procurement and nonprocurement transactions.
                </P>
                <P>This proposed rule seeks to change the FAR so that the two systems will be in closer alignment where appropriate, and incorporates existing practices within the suspension and debarment systems that are not currently in the FAR. The intent behind this alignment is to enhance transparency and consistency within the Government's suspension and debarment procedures.</P>
                <P>
                    Currently, the two suspension and debarment systems are similar, but not identical. Although the two suspension and debarment rules at their core are designed toward the same end, follow the same general principles, and use essentially the same basic action notice and decision-making process, there are some differences between the rules. Some are definitional (
                    <E T="03">e.g.,</E>
                     the NCR definition of “civil judgment” is more comprehensive than the FAR definition), and some are procedural (
                    <E T="03">e.g.,</E>
                     the NCR and FAR procedures differ regarding deadlines for suspending and debarring officials to make exclusion decisions after the record closes). One difference which is not being changed in this rule is that a notice of proposed debarment under the FAR has the effect of immediately excluding the party but does not have this effect in the NCR. This is done in part in recognition of the necessity to continue to protect the Government's interests and taxpayer's money by minimizing business risk where procurements are involved. The FAR gives the suspending and debarring official two tools with immediate exclusion effect upon imposition—a 
                    <PRTPAGE P="1044"/>
                    proposal for debarment and a suspension. Both have been in the FAR as recognized tools for decades, with different standards for use. The Federal Acquisition Regulatory Council (FAR Council) notes that contracts are more likely than nonprocurement transactions, such as Federal financial assistance, to require immediate exclusion when something goes wrong. See 2 CFR 180.810. Participants in nonprocurement transactions—while subject to the terms and conditions of a Federal award—are typically required to meet overall program goals and objectives, rather than perform to an exact contractual requirement. Federal financial assistance typically is for public purposes of support or economic stimulation, rather than for the direct benefit of the U.S. Government. See 31 U.S.C. 6303 to 6305. In this rule the FAR Council is continuing to keep both tools, so the suspending and debarring official will continue to have the discretion to choose whichever tool is appropriate for the particular situation. This rule also recognizes the use of a pre-notice letter, for the suspending and debarring official to consider using instead of an immediate exclusion.
                </P>
                <P>
                    The importance of protecting the Government's interests is reflected in recurring Appropriations Act language since 2012 (see, 
                    <E T="03">e.g.,</E>
                     Pub. L. 112-55, Pub. L. 112-74, and Pub. L. 117-328), which states that funds may not be used to enter into a contract with any corporation that was convicted of a felony criminal violation under Federal law within the preceding 24 months, unless a Federal agency has considered suspension or debarment of the corporation and has made a determination that further action is not necessary to protect the interests of the Government. In instances in which an agency has issued a proposed debarment under the FAR, a Federal agency has considered that further action may be necessary concerning that particular party, and therefore, the exclusion is consistent with statutory intent.
                </P>
                <HD SOURCE="HD1">II. Discussion and Analysis</HD>
                <P>The following summarizes the proposed changes to the FAR:</P>
                <P>The definition of “suspending and debarring official” is added at FAR 2.101, and standardized throughout the FAR, to denote the title of the Government official who is authorized to impose suspension and debarment actions for the Federal Government. New definitions have been added at FAR 9.403 for “administrative agreement”, “conviction”, “pre-notice letter”, and “voluntary exclusion”. The current definition of “civil judgment” is also updated for the rule. The definitions of “conviction”, “voluntary exclusion”, and “civil judgment” are equivalent to the NCR definitions at 2 CFR 180.920, 180.1020, and 180.915, respectively.</P>
                <P>The rationale for adding a definition of “administrative agreement” to the FAR is that over the years suspending and debarring officials have come to recognize the value of resolving present responsibility concerns through administrative agreements. Such agreements provide an alternative for the Government to implement protective measures short of exclusion, particularly for those contractors who are working toward present responsibility but need additional time to implement appropriate remedial measures to mitigate the business risk to the Government. Administrative agreements often require that the parties to the agreement take certain verifiable actions to demonstrate present responsibility within a prescribed timeframe, such as the implementation of enhanced internal corporate governance practices and procedures and/or the use of independent third-party monitors. In unique circumstances, an administrative agreement may include a contractor's agreement not to participate in certain procurement and/or nonprocurement transactions or in specific activities for the term of the administrative agreement or pending the implementation of appropriate remedial measures. Administrative agreements are fact-specific, and therefore vary between agencies and from one agreement to another. Currently, FAR part 9 mentions administrative agreements in the context of the statutory requirement that administrative agreements must be entered into the Federal Awardee Performance and Integrity Information System (FAPIIS) (see FAR 9.406-3(f) and 9.407-3(e)). However, the FAR is silent as to its definition. Incorporating a definition will provide clarity as to what constitutes an administrative agreement.</P>
                <P>The rationale for a revised definition of “conviction” is that fact-finding proceedings should not be necessary when there is a sufficient evidentiary basis that the contractor was responsible for the misconduct for purposes of a proposed debarment. The definition of “conviction” in 2 CFR 180.920 is adopted and means a judgment or any other determination of guilt of a criminal offense by any court of competent jurisdiction, whether entered upon a verdict or plea, including a plea of nolo contendere; or any other resolution that is the functional equivalent of a judgment, including probation before judgment and deferred prosecution. A disposition without the participation of the court is the functional equivalent of a judgment only if it includes an admission of guilt. The new definition is located at FAR 9.403 rather than FAR 2.101, so it applies only to FAR subpart 9.4.</P>
                <P>The new definition of “pre-notice letter” clarifies that the letter is not mandatory. Suspension and debarment procedures under both the FAR and the NCR recognize the authority of agencies to handle actions as informally as practicable consistent with principles of fundamental fairness (see FAR 9.406-3(b)(1) and 9.407-3(b)(1); 2 CFR 180.610). Accordingly, suspending and debarring officials may choose to engage in preliminary discussions with potential respondents or their counsel under a variety of circumstances. Adding a definition of “pre-notice letter” reflects existing practice. The Interagency Suspension and Debarment Committee has tracked the issuance of pre-notice letters in its reports since fiscal year 2009; the use of the letters has significantly increased over the past decade. Including a definition highlights another option that agencies may consider to resolve concerns involving contractor present responsibility, short of a formal notice under the suspension and debarment rules.</P>
                <P>A new definition is added for “voluntary exclusion” which applies throughout FAR part 9 to denote the procedures the Federal Government uses with contractors for these types of agreements. Voluntary exclusions are briefly described in the NCR at 2 CFR 180.640 and 180.645. The FAR does not currently describe voluntary exclusions. A contractor may choose to agree to a voluntary exclusion so that it may represent itself in a more favorable light to various constituencies including but not limited to customers, creditors, and the public at large, by indicating that it chose to voluntarily exclude itself rather than be being involuntarily excluded by the Government through suspension or debarment. A contractor who is voluntarily excluded will be placed on the excluded parties list in the System for Award Management (SAM); the exclusion must have Governmentwide effect pursuant to the terms of the voluntary exclusion agreement.</P>
                <P>
                    FAR 9.406-1(a) contains remedial measures and mitigating factors for the debarring official to consider. The suspension regulations incorporate the factors by reference at FAR 9.407-1(b)(2). The proposed rule seeks to add 
                    <PRTPAGE P="1045"/>
                    seven new aggravating or mitigating factors that a suspending and debarring official should consider before arriving at a decision. The factors are equivalent to NCR factors at 2 CFR 180.860(a) through (f), (j), (k), (m), and (s). Unlike the FAR, the NCR makes it clear that aggravating factors may also be considered by the suspending and debarring official. Incorporating these aggravating factors will provide consistency between the two rules, as well as more guidance and increased options for the suspending and debarring official to consider when making present responsibility determinations.
                </P>
                <P>FAR 9.406-3(b)(1) and 9.407-3(b)(1) state that agencies may establish informal procedures governing the suspension and debarment decision-making process. Accordingly, this rule proposes changes that would authorize suspending and debarring officials to allow contractors and their representatives to present matters in opposition via additional methods of communication, such as telephone or internet, as such methods of communication are becoming more widely used and are consistent with principles of fundamental fairness. The new flexibilities are being added so that the Government and contractors will have additional means of communication when situations such as COVID-19 arise and the ability of the parties to meet in person is limited.</P>
                <P>FAR 9.406-3(c)(1) and 9.407-3(c) add language that will allow the suspending and debarring official the flexibility to issue a notice of proposed debarment or notice of suspension by mail, facsimile, email, or certified mail with return receipt requested. The new flexibilities are being added so that the Government will have additional means of communication when emergency situations such as COVID-19 arise, and when delivering notices to contractors abroad; the use of the new methods is not restricted to those situations. The NCR allows notice to be served in person, sent by certified mail or its equivalent, or sent electronically by email or facsimile; see 2 CFR 180.975. If a contractor makes a case for nonreceipt of notice, FAR 9.406-4 allows a debarred person to seek reinstatement by requesting the debarment period or extent of debarment be reduced.</P>
                <P>FAR 9.406-3(c)(2) adds language which requires the suspending and debarring official to send the notice of proposed debarment to the contractor, the contractor's identified counsel for purposes of the administrative proceedings, or the contractor's agent for service of process. This does not go quite as far as the NCR, which allows notice to be sent instead to a partner, officer, director, owner, or joint venture partner; see 2 CFR 180.615. For each specifically named affiliate, the suspending and debarring official must send the notice to the affiliate itself, the affiliate's identified counsel for purposes of the administrative proceedings, or the affiliate's agent for service of process. The language is added so that the Government will have the widest latitude in assuring that the notice is received. These are the minimum notice requirements.</P>
                <P>FAR 9.406-3(c)(3)(viii) and (ix), and 9.407-3(c)(7) and (8) require that the contractor respond with specific facts and other information, including identifying all of its affiliates. The language is substantively equivalent to the NCR language at 2 CFR 180.825 and 180.730.</P>
                <P>FAR 9.406-3(d)(1) addresses the time a suspending and debarring official has to make a debarment decision in deciding actions based upon a conviction or civil judgment, or in which there is no genuine dispute over material facts. If no suspension is in effect, the time currently is 30 working days after receipt of any information and argument submitted by the contractor, unless the suspending and debarring official extends this period for good cause. Under this proposed rule, the 30 working days time frame would change to 45 days, which under the definition of “day” at FAR 2.101 means calendar days. The NCR language at 2 CFR 180.870(a) is 45 days after the closing of the official record. The FAR language is changed to reflect 45 days after the closing of the official record. In addition to harmonizing the NCR and the FAR, the change will avoid conflicts with how other countries compute working days, in light of national or religious holidays. Forty-five calendar days is roughly equivalent to thirty working days.</P>
                <P>FAR 9.406-3(e) and 9.407-3(d)(4) adds language that specifies that when the suspending and debarring official sends the notice of their decision, the notice procedures set forth in FAR 9.406-3(c)(1) and (2) shall be used. The new flexibilities are being added so that the Government will have additional means of communication when situations such as COVID-19 arise, and when delivering notices to contractors abroad; the use of the new methods is not restricted to those situations.</P>
                <P>FAR 9.406-3(f) and 9.407-3(e)(1) add the requirement for the suspending and debarring official to enter an administrative agreement into FAPIIS, whether the agreement resolves a suspension or debarment action or whether it was a potential suspension or debarment action. This requirement is being added to confirm that potential suspension or debarment actions are covered.</P>
                <P>FAR 9.406-3(g) and 9.407-3(f) add the requirement for the suspending and debarring official to enter voluntary exclusions into the excluded parties section of SAM as is currently required under the NCR. This requirement is being added so that selecting officials can review these types of exclusions before awards are made.</P>
                <P>FAR 9.406-3(h) and 9.407-3(g) confirm that, prior to initiating a proposed suspension or debarment, the suspending and debarring official may issue a pre-notice letter alerting the contractor to potential future action. The definition of “pre-notice letter” is added at FAR 9.403. A suspending and debarring official is not required to send a pre-notice letter prior to initiating suspension or debarment action.</P>
                <P>Language is added to FAR 9.407-1(b)(1) explaining that the suspending and debarring official has wide discretion to impose suspensions when immediate action is necessary to protect the Government's interest. New language is also added to the section indicating that an indictment, or other official findings by Federal, State, or local bodies that determine factual and/or legal matters, constitutes adequate evidence for purposes of suspension actions. The new language is equivalent to the NCR language at 2 CFR 180.705(b) and (c).</P>
                <P>FAR 9.407-3(b)(2), (c)(6), and (d) revise the list of parties who can contribute advice on pending or contemplated legal proceedings, to include “advice from the Department of Justice, a U.S. Attorney's office, State attorney general's office, or a State or local prosecutor's office.” The language is equivalent to the NCR language at 2 CFR 180.735(a)(4). The FAR currently fails to take into account that suspensions can be based on State and local legal proceedings.</P>
                <P>
                    FAR 9.407-4(b) adds to the parties who may request a six-month extension of a suspension, when legal proceedings have not been initiated within 12 months after the date of the suspension notice. The parties would change from “an Assistant Attorney General” to “an office of a U.S. Assistant Attorney General, U.S. Attorney, or other responsible prosecuting official”. The language is equivalent to the NCR language at 2 CFR 180.760(b). Coordinating the need for an extension with an Assistant Attorney General as 
                    <PRTPAGE P="1046"/>
                    directed by the FAR is burdensome and lengthy. On the other hand, agencies have reported that under the more flexible provisions of the NCR they have often coordinated extensions in a week.
                </P>
                <P>Notwithstanding the proposed and/or final rule, terms of voluntary exclusion and administrative agreements executed prior to the final rule will remain in effect.</P>
                <P>The proposed rule also makes conforming changes in FAR subparts 2, 3, 22, 23, 25, 33, and 52.</P>
                <HD SOURCE="HD1">III. Applicability to Contracts at or Below the Simplified Acquisition Threshold (SAT) and for Commercial Products (Including Commercially Available Off-the-Shelf (COTS) Items) or for Commercial Services</HD>
                <P>This proposed rule does not create new solicitation provisions or contract clauses, nor does it change the applicability or burden of any existing provisions or clauses included in solicitations and contracts valued at or below the SAT, or for commercial products, including COTS items, or for commercial services.</P>
                <HD SOURCE="HD1">IV. Expected Impact of the Rule</HD>
                <P>This proposed rule seeks to improve consistency between the procurement and nonprocurement procedures on suspension and debarment. These changes in the FAR will bring the two systems into closer alignment, which will enhance transparency and consistency within the Government's suspension and debarment procedures. This will allow contractors a better understanding of how the two systems' procedures relate to each other.</P>
                <HD SOURCE="HD1">V. Executive Orders 12866 and 13563</HD>
                <P>Executive Orders (E.O.s) 12866, as amended by E.O. 14094, 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). E.O. 13563 emphasizes the importance of quantifying both costs and benefits, of reducing costs, of harmonizing rules, and of promoting flexibility. This is not a significant regulatory action and, therefore, was not subject to review under Section 6(b) of E.O. 12866, Regulatory Planning and Review, dated September 30, 1993.</P>
                <HD SOURCE="HD1">VI. Regulatory Flexibility Act</HD>
                <P>DoD, GSA, and NASA do not expect this proposed rule, if finalized, to have a significant economic impact on a substantial number of small entities within the meaning of the Regulatory Flexibility Act, 5 U.S.C. 601-612, because the rule imposes minor procedural changes that are anticipated to have a positive impact on small entities. However, an Initial Regulatory Flexibility Analysis (IRFA) has been performed and is summarized as follows:</P>
                <EXTRACT>
                    <P>DoD, GSA, and NASA are proposing to amend the FAR to improve consistency between the procurement and nonprocurement procedures on suspension and debarment, based on recommendations of the Interagency Suspension and Debarment Committee.</P>
                    <P>The objective of this proposed rule is to more closely align the two systems of procurement and nonprocurement suspension and debarment to enhance transparency and consistency within the FAR system. Promulgation of the FAR is authorized by 40 U.S.C. 121(c); 10 U.S.C. chapter 4 and 10 U.S.C. chapter 137 legacy provisions (see 10 U.S.C. 3016); and 51 U.S.C. 20113.</P>
                    <P>The Exclusions section of SAM does not contain data on the size of an excluded party as size is only specifically determined contract by contract based on the North American Industry Classification System (NAICS) code. When the entity is recorded in SAM as an excluded party, the suspending and debarring official identifies the entity as either (1) an individual, (2) firm, (3) vessel, or (4) special entity designation. Collection of unique identification numbers are on “firms” and optionally on “special entity designations”.</P>
                    <P>Data was analyzed by obtaining the list of entities that were excluded in fiscal years 2017, 2018, and 2019. Next, the entities on that list with unique identification numbers were compared against the SAM data to see if any were actively registered in those fiscal years for all awards. Lastly, the entities that would be considered small businesses based on their primary NAICS code were identified.</P>
                    <P>The following is a breakdown of those distinct entities which had an entity registration in active status and concurrent active exclusion record per fiscal year (FY):</P>
                    <GPOTABLE COLS="5" OPTS="L2,tp0,i1" CDEF="s50,12,12,12,12">
                        <TTITLE> </TTITLE>
                        <BOXHD>
                            <CHED H="1">Suspension and debarment—SAM exclusions</CHED>
                            <CHED H="1">FY 2017</CHED>
                            <CHED H="2">
                                SB/total
                                <LI>exclusions</LI>
                            </CHED>
                            <CHED H="1">FY 2018</CHED>
                            <CHED H="2">
                                SB/total
                                <LI>exclusions</LI>
                            </CHED>
                            <CHED H="1">FY 2019</CHED>
                            <CHED H="2">
                                SB/total
                                <LI>exclusions</LI>
                            </CHED>
                            <CHED H="1">Median</CHED>
                            <CHED H="2">SB %</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Small Business/Total Exclusions</ENT>
                            <ENT>152/203</ENT>
                            <ENT>189/253</ENT>
                            <ENT>180/245</ENT>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">Small Business Percentage</ENT>
                            <ENT>75%</ENT>
                            <ENT>75%</ENT>
                            <ENT>73.4%</ENT>
                            <ENT>75</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>The proposed rule does impose minor procedural changes in compliance requirements on contractors and minor process procedures for the Government. However, this alignment enhances transparency and consistency within the Government's suspension and debarment procedures reducing the complexities in understanding of the two distinct processes and procedural requirements for suspension and debarment Governmentwide.</P>
                    <P>The proposed rule does not include any reporting or recordkeeping requirements. The rule does not contain any information collection requirements that require the approval of the Office of Management and Budget under the Paperwork Reduction Act (44 U.S.C. chapter 35) or other compliance requirements for small entities.</P>
                    <P>44 U.S.C. 3518 and 5 CFR 1320.4(a)(2) give an exception for the collection of information during the conduct of an administrative action, investigation, or audit involving an agency against specific individuals or entities.</P>
                    <P>This proposed rule does not duplicate, overlap, or conflict with any other Federal rules.</P>
                    <P>DoD, GSA, and NASA were unable to identify any significant alternatives.</P>
                </EXTRACT>
                <P>The Regulatory Secretariat Division has submitted a copy of the IRFA to the Chief Counsel for Advocacy of the Small Business Administration. A copy of the IRFA may be obtained from the Regulatory Secretariat Division. DoD, GSA, and NASA invite comments from small business concerns and other interested parties on the expected impact of this rule on small entities.</P>
                <P>DoD, GSA, and NASA will also consider comments from small entities concerning the existing regulations in subparts affected by the rule in accordance with 5 U.S.C. 610. Interested parties must submit such comments separately and should cite “5 U.S.C. 610 (FAR Case 2019-015)”, in correspondence.</P>
                <HD SOURCE="HD1">VII. Paperwork Reduction Act</HD>
                <P>This rule does not contain any information collection requirements that require the approval of the Office of Management and Budget under the Paperwork Reduction Act (44 U.S.C. 3501-3521).</P>
                <LSTSUB>
                    <PRTPAGE P="1047"/>
                    <HD SOURCE="HED">List of Subjects in 48 CFR Parts 2, 3, 9, 22, 23, 25, 33, and 52</HD>
                    <P>Government procurement.</P>
                </LSTSUB>
                <SIG>
                    <NAME>William F. Clark,</NAME>
                    <TITLE>Director, Office of Government-Wide Acquisition Policy, Office of Acquisition Policy, Office of Government-wide Policy.</TITLE>
                </SIG>
                <P>Therefore, DoD, GSA, and NASA propose amending 48 CFR parts 2, 3, 9, 22, 23, 25, 33, and 52 as set forth below:</P>
                <AMDPAR>1. The authority citation for 48 CFR parts 2, 3, 9, 22, 23, 25, 33, and 52 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 40 U.S.C. 121(c); 10 U.S.C. chapter 4 and 10 U.S.C. chapter 137 legacy provisions (see 10 U.S.C. 3016); and 51 U.S.C. 20113.</P>
                </AUTH>
                <PART>
                    <HD SOURCE="HED">PART 2—DEFINITIONS OF WORDS AND TERMS</HD>
                </PART>
                <AMDPAR>2. Amend section 2.101, in paragraph (b)(2) by—</AMDPAR>
                <AMDPAR>
                    a. In the definition of “Conviction”, removing “
                    <E T="03">nolo contendere.</E>
                    ” and adding “nolo contendere. For use in subpart 9.4, see the definition at 9.403.” in its place;
                </AMDPAR>
                <AMDPAR>b. In the definition of “Debarment”, removing “a debarring” and adding “a suspending and debarring” in its place;</AMDPAR>
                <AMDPAR>c. Adding in alphabetical order the definition of “Suspending and debarring official”; and</AMDPAR>
                <AMDPAR>d. In the definition of “Suspension”, removing “suspending official” and adding “suspending and debarring official” in its place.</AMDPAR>
                <P>The addition reads as follows:</P>
                <SECTION>
                    <SECTNO>2.101</SECTNO>
                    <SUBJECT>Definitions.</SUBJECT>
                    <STARS/>
                    <P>(b) * * *</P>
                    <P>(2) * * *</P>
                    <P>
                        <E T="03">Suspending and debarring official</E>
                         means—
                    </P>
                    <P>(1) An agency head; or</P>
                    <P>(2) A designee authorized by the agency head to impose a suspension and/or a debarment.</P>
                    <STARS/>
                </SECTION>
                <PART>
                    <HD SOURCE="HED">PART 3—IMPROPER BUSINESS PRACTICES AND PERSONAL CONFLICTS OF INTEREST</HD>
                    <SECTION>
                        <SECTNO>3.104-7</SECTNO>
                        <SUBJECT>[Amended]</SUBJECT>
                    </SECTION>
                </PART>
                <AMDPAR>3. Amend section 3.104-7 by removing from paragraph (d)(3) “suspending or” and adding “suspending and” in its place.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 9—CONTRACTOR QUALIFICATIONS</HD>
                    <SECTION>
                        <SECTNO>9.104-5</SECTNO>
                        <SUBJECT>[Amended]</SUBJECT>
                    </SECTION>
                </PART>
                <AMDPAR>4. Amend section 9.104-5 by removing from paragraph (b)(3) “suspending or” and adding “suspending and” in its place.</AMDPAR>
                <AMDPAR>5. Amend section 9.104-6 by—</AMDPAR>
                <AMDPAR>a. Revising paragraph (b)(4); and</AMDPAR>
                <AMDPAR>b. Removing from paragraph (c) “debarred or suspended” and adding “debarred, or suspended, or has agreed to a voluntary exclusion” in its place.</AMDPAR>
                <P>The revision reads as follows:</P>
                <SECTION>
                    <SECTNO>9.104-6</SECTNO>
                    <SUBJECT>Federal Awardee Performance and Integrity Information System.</SUBJECT>
                    <STARS/>
                    <P>(b) * * *</P>
                    <P>
                        (4) Since FAPIIS may contain information on any of the offeror's previous contracts and information covering a 5-year period, some of that information may not be relevant to a determination of present responsibility, 
                        <E T="03">e.g.,</E>
                         a prior administrative action such as debarment, suspension, voluntary exclusion, or administrative agreement, that has expired or otherwise been resolved, or information relating to contracts for completely different products or services.
                    </P>
                    <STARS/>
                </SECTION>
                <SECTION>
                    <SECTNO>9.402</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>6. Amend section 9.402 by removing from paragraph (d) “Interagency Committee on Debarment and Suspension” and adding “Interagency Suspension and Debarment Committee” in its place.</AMDPAR>
                <AMDPAR>7. Amend section 9.403 by—</AMDPAR>
                <AMDPAR>a. Adding in alphabetical order the definition of “Administrative agreement”;</AMDPAR>
                <AMDPAR>b. Revising the definition of “Civil judgment”;</AMDPAR>
                <AMDPAR>c. Adding in alphabetical order the definition of “Conviction”;</AMDPAR>
                <AMDPAR>d. Removing the definition of “Debarring official”;</AMDPAR>
                <AMDPAR>e. Adding a sentence to the end of the definition of “Nonprocurement Common Rule”;</AMDPAR>
                <AMDPAR>f. Adding in alphabetical order the definition of “Pre-notice letter”;</AMDPAR>
                <AMDPAR>g. Removing the definition of “Suspending official”; and</AMDPAR>
                <AMDPAR>h. Adding in alphabetical order the definition of “Voluntary exclusion”.</AMDPAR>
                <P>The additions and revisions read as follows:</P>
                <SECTION>
                    <SECTNO>9.403</SECTNO>
                    <SUBJECT>Definitions.</SUBJECT>
                    <STARS/>
                    <P>
                        <E T="03">Administrative agreement</E>
                         means an agreement between an agency suspending and debarring official and the contractor used to resolve a suspension or debarment proceeding, or a potential suspension or debarment proceeding.
                    </P>
                    <STARS/>
                    <P>
                        <E T="03">Civil judgment</E>
                         means the disposition of a civil action by any court of competent jurisdiction, whether by verdict, decision, settlement, stipulation, other disposition that creates a civil liability for the complained of wrongful acts, or a final determination of liability under the Program Fraud Civil Remedies Act of 1986 (31 U.S.C. 3801-3812).
                    </P>
                    <STARS/>
                    <P>
                        <E T="03">Conviction</E>
                         means—
                    </P>
                    <P>(1) A judgment or any other determination of guilt of a criminal offense by any court of competent jurisdiction, whether entered upon a verdict or plea, including a plea of nolo contendere; or</P>
                    <P>(2) Any other resolution that is the functional equivalent of a judgment establishing a criminal offense by a court of competent jurisdiction, including probation before judgment and deferred prosecution. A disposition without the participation of the court is the functional equivalent of a judgment only if it includes an admission of guilt.</P>
                    <STARS/>
                    <P>
                        <E T="03">Nonprocurement Common Rule</E>
                         * * * See 2 CFR part 180 and agency enacting regulations.
                    </P>
                    <P>
                        <E T="03">Pre-notice letter</E>
                         means a written correspondence issued to a potential respondent in a suspension or debarment matter, which does not immediately result in an exclusion or ineligibility. The letter is issued at the discretion of the suspending and debarring official. The letter is not a mandatory step in the suspension or debarment process.
                    </P>
                    <STARS/>
                    <P>
                        <E T="03">Voluntary exclusion</E>
                         means a contractor's written agreement to be excluded for a period under the terms of a settlement between the contractor and the suspending and debarring official of one or more agencies. A voluntary exclusion must have Governmentwide effect.
                    </P>
                </SECTION>
                <SECTION>
                    <SECTNO>9.404</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>8. Amend section 9.404 by—</AMDPAR>
                <AMDPAR>a. Removing from paragraph (b)(1) “debarment, declared ineligible,” and adding “debarment, voluntarily excluded, declared ineligible,” in its place;</AMDPAR>
                <AMDPAR>b. Removing from paragraph (c)(3) introductory text “exclusion accomplished” and adding “exclusion, including each voluntary exclusion, accomplished” in its place; and</AMDPAR>
                <AMDPAR>c. Removing from paragraph (c)(4) “or proposed debarment taken by” and adding “proposed debarment, or voluntary exclusion taken or entered into by” in its place.</AMDPAR>
                <AMDPAR>9. Amend section 9.405 by—</AMDPAR>
                <AMDPAR>
                    a. Revising paragraph (a); and
                    <PRTPAGE P="1048"/>
                </AMDPAR>
                <AMDPAR>b. Removing from paragraph (d) “or proposed for debarment are” and adding “proposed for debarment, or voluntarily excluded, are” in its place.</AMDPAR>
                <P>The revision reads as follows:</P>
                <SECTION>
                    <SECTNO>9.405</SECTNO>
                    <SUBJECT>Effect of listing.</SUBJECT>
                    <P>(a) Contractors debarred, suspended, proposed for debarment, or voluntarily excluded, are excluded from receiving contracts, and agencies shall not solicit offers from, award contracts to, or consent to subcontracts with these contractors, unless the agency head determines that there is a compelling reason for such action (see 9.405-1(a)(2), 9.405-2, 9.406-1(d), 9.407-1(d), and 23.506(e)). Contractors debarred, suspended, proposed for debarment, or voluntarily excluded, are also excluded from conducting business with the Government as agents or representatives of other contractors.</P>
                    <STARS/>
                </SECTION>
                <SECTION>
                    <SECTNO>9.405-1</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>10. Amend section 9.405-1 by—</AMDPAR>
                <AMDPAR>
                    a. Removing from paragraph (a) heading “
                    <E T="03">or proposed for debarment.</E>
                    ” and adding “
                    <E T="03">proposed for debarment, or voluntarily excluded.</E>
                    ” in its place;
                </AMDPAR>
                <AMDPAR>b. Removing from paragraph (a)(1) “or proposed debarment of” and “or proposed for debarment unless” and adding “proposed debarment, or voluntary exclusion, of” and “proposed for debarment, or voluntarily excluded, unless” in their places, respectively; and</AMDPAR>
                <AMDPAR>c. Removing from paragraph (a)(2) “or proposed for debarment, unless” and adding “proposed for debarment, or voluntarily excluded, unless” in its place.</AMDPAR>
                <SECTION>
                    <SECTNO>9.405-2</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>11. Amend section 9.405-2 by—</AMDPAR>
                <AMDPAR>a. Removing from paragraph (a) “or proposed for debarment is” and adding “proposed for debarment, or voluntarily excluded, is” in its place; and</AMDPAR>
                <AMDPAR>b. Removing from paragraph (b) introductory text “or proposed for debarment, unless”, “or proposed for debarment as”, and “or Proposed for Debarment to” and adding “proposed for debarment, or voluntarily excluded, unless”, “proposed for debarment, or voluntarily excluded, as” and “Proposed for Debarment, or Voluntarily Excluded, to” in their places, respectively.</AMDPAR>
                <AMDPAR>12. Revise section 9.406-1 to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>9.406-1</SECTNO>
                    <SUBJECT>General.</SUBJECT>
                    <P>(a) It is the suspending and debarring official's responsibility to determine whether debarment is in the Government's interest. The suspending and debarring official may, in the public interest, debar a contractor for any of the causes in 9.406-2, using the procedures in 9.406-3. The existence of a cause for debarment, however, does not necessarily require that the contractor be debarred; the seriousness of the contractor's acts or omissions and any remedial measures, mitigating factors, or aggravating factors should be considered in making any debarment decision. Before arriving at any debarment decision, the suspending and debarring official should consider factors such as the following:</P>
                    <P>(1) Whether the contractor had effective standards of conduct and internal control systems in place at the time of the activity which constitutes cause for debarment or had adopted such procedures prior to any Government investigation of the activity cited as a cause for debarment.</P>
                    <P>(2) Whether the contractor brought the activity cited as a cause for debarment to the attention of the appropriate Government agency in a timely manner.</P>
                    <P>(3) Whether the contractor has fully investigated the circumstances surrounding the cause for debarment and, if so, made the result of the investigation available to the suspending and debarring official.</P>
                    <P>(4) Whether the contractor cooperated fully with Government agencies during the investigation and any court or administrative action.</P>
                    <P>(5) Whether the contractor has paid or has agreed to pay all criminal, civil, and administrative liability for the improper activity, including any investigative or administrative costs incurred by the Government, and has made or agreed to make full restitution.</P>
                    <P>(6) Whether the contractor has taken appropriate disciplinary action against the individuals responsible for the activity which constitutes cause for debarment.</P>
                    <P>(7) Whether the contractor has implemented or agreed to implement remedial measures, including any identified by the Government.</P>
                    <P>(8) Whether the contractor has instituted or agreed to institute new or revised review and control procedures and ethics training programs.</P>
                    <P>(9) Whether the contractor has had adequate time to eliminate the circumstances within the contractor's organization that led to the cause for debarment.</P>
                    <P>(10) Whether the contractor's management recognizes and understands the seriousness of the misconduct giving rise to the cause for debarment and has implemented programs to prevent recurrence.</P>
                    <P>(11) Whether the contractor has a pattern or prior history of wrongdoing, the frequency of incidents and/or duration of the wrongdoing, and the actual or potential harm or impact that results, or may result, from the wrongdoing.</P>
                    <P>(12) Whether and to what extent the contractor planned, initiated, or carried out the wrongdoing, and the kind of positions held by the individuals involved in the wrongdoing.</P>
                    <P>(13) Whether the wrongdoing was pervasive within the contractor's organization.</P>
                    <P>(14) Whether the contractor's principals tolerated the offense.</P>
                    <P>(15) Whether the contractor is or has been excluded or disqualified by an agency of the Federal Government or has not been allowed to participate in State or local contracts or assistance agreements on a basis of conduct similar to one or more of the causes for debarment specified in this part.</P>
                    <P>(16) Whether the contractor has entered into an administrative agreement with a Federal agency or a similar agreement with a State or local government that is not Governmentwide but is based on conduct similar to one or more of the causes for debarment specified in this part.</P>
                    <P>(17) Whether there are any other factors appropriate to the circumstances of a particular case.</P>
                    <P>(b) The existence or nonexistence of any aggravating or mitigating factors or remedial measures such as set forth in paragraph (a) is not necessarily determinative of a contractor's present responsibility. Accordingly, if a cause for debarment exists, the contractor has the burden of demonstrating, to the satisfaction of the suspending and debarring official, its present responsibility and that debarment is not necessary.</P>
                    <P>(c) Debarment constitutes debarment of all divisions or other organizational elements of the contractor, unless the debarment decision is limited by its terms to specific divisions, organizational elements, or commodities. The suspending and debarring official may extend the debarment decision to include any affiliates of the contractor if they are—</P>
                    <P>(1) Specifically named; and</P>
                    <P>(2) Given written notice of the proposed debarment and an opportunity to respond (see 9.406-3(c)).</P>
                    <P>
                        (d) A contractor's debarment, or proposed debarment, shall be effective throughout the executive branch of the Government, unless the agency head or a designee (except see 23.506(e)) states in writing the compelling reasons 
                        <PRTPAGE P="1049"/>
                        justifying continued business dealings between that agency and the contractor.
                    </P>
                    <P>(e)(1) When the suspending and debarring official has authority to debar contractors from both acquisition contracts pursuant to this regulation and contracts for the purchase of Federal personal property pursuant to the Federal Management Regulations (FMR) 41 CFR part 102-38 (see section 102-38.175, that official shall consider simultaneously debarring the contractor from the award of acquisition contracts and from the purchase of Federal personal property.</P>
                    <P>(2) When debarring a contractor from the award of acquisition contracts and from the purchase of Federal personal property, the debarment notice shall so indicate and the appropriate FAR and FMR citations shall be included.</P>
                </SECTION>
                <SECTION>
                    <SECTNO>9.406-2</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>13. Amend section 9.406-2 by removing from the introductory text “The debarring” and adding “The suspending and debarring” in its place.</AMDPAR>
                <AMDPAR>14. Amend section 9.406-3 by—</AMDPAR>
                <AMDPAR>a. Removing from paragraph (a) “the debarring official” and adding “the suspending and debarring official” in its place;</AMDPAR>
                <AMDPAR>b. Adding two sentences to the end of paragraph (b)(1);</AMDPAR>
                <AMDPAR>c. Revising paragraph (c);</AMDPAR>
                <AMDPAR>d. Revising the heading of paragraph (d);</AMDPAR>
                <AMDPAR>e. Revising paragraph (d)(1);</AMDPAR>
                <AMDPAR>f. Removing from paragraph (d)(2)(i) “The debarring official” and adding “The suspending and debarring official” in its place;</AMDPAR>
                <AMDPAR>g. Removing from paragraph (d)(2)(ii) “The debarring official” (twice) and adding “The suspending and debarring official” (twice) in their places;</AMDPAR>
                <AMDPAR>h. Removing from paragraph (d)(2)(iii) “The debarring official's” and adding “The suspending and debarring official's” in its place;</AMDPAR>
                <AMDPAR>i. Revising paragraphs (e) heading and (e)(1) introductory text;</AMDPAR>
                <AMDPAR>j. Removing from paragraph (e)(1)(iv) “9.406-1(c)” and adding “9.406-1(d)” in its place;</AMDPAR>
                <AMDPAR>k. Removing from paragraph (e)(2) “the debarring official” and “certified mail, return receipt requested” and adding “the suspending and debarring official” and “the procedures set forth in 9.406-3(c)(1) and (2)” in their places, respectively;</AMDPAR>
                <AMDPAR>l. Revising paragraph (f); and</AMDPAR>
                <AMDPAR>m. Adding paragraphs (g) and (h).</AMDPAR>
                <P>The revisions and additions read as follows:</P>
                <SECTION>
                    <SECTNO>9.406-3</SECTNO>
                    <SUBJECT>Procedures.</SUBJECT>
                    <STARS/>
                    <P>(b) * * *</P>
                    <P>(1) * * * The suspending and debarring official may use flexible procedures to allow a contractor to present matters in opposition in person or remotely through appropriate technology. If so, the suspending and debarring official should change the notice in paragraph (c)(3)(iv) of this section to include those flexible procedures.</P>
                    <STARS/>
                    <P>
                        (c) 
                        <E T="03">Notice of proposal to debar.</E>
                         A notice of proposed debarment shall be issued by the suspending and debarring official to the contractor and any specifically named affiliates.
                    </P>
                    <P>(1) The written notice shall be sent—</P>
                    <P>(i) By mail, to the last known street address;</P>
                    <P>(ii) To the last known email address; or</P>
                    <P>(iii) By certified mail to the last known street address with return receipt requested.</P>
                    <P>(2) The notice shall be sent—</P>
                    <P>(i) To the contractor, the contractor's identified counsel for purposes of the administrative proceedings, or the contractor's agent for service of process; and</P>
                    <P>(ii) For each specifically named affiliate, to the affiliate itself, the affiliate's identified counsel for purposes of the administrative proceedings, or the affiliate's agent for service of process.</P>
                    <P>(3) The notice shall state—</P>
                    <P>(i) That debarment is being considered;</P>
                    <P>(ii) The reasons for the proposed debarment in terms sufficient to put the contractor on notice of the conduct or transaction(s) upon which it is based;</P>
                    <P>(iii) The cause(s) relied upon under 9.406-2 for proposing debarment;</P>
                    <P>(iv) That, within 30 days after receipt of the notice, the contractor may submit, in person, in writing, or through a representative, information and argument in opposition to the proposed debarment, including any additional specific information that raises a genuine dispute over the material facts;</P>
                    <P>(v) The agency's procedures governing debarment decisionmaking;</P>
                    <P>(vi) The effect of the issuance of the notice of proposed debarment;</P>
                    <P>(vii) The potential effect of an actual debarment;</P>
                    <P>(viii) That in addition to any information and argument in opposition to a proposed debarment, the contractor must identify—</P>
                    <P>(A) Specific facts that contradict the statements contained in the notice of proposed debarment. Include any information about any of the factors listed in 9.406-1(a). A general denial is insufficient to raise a genuine dispute over facts material to the proposed debarment;</P>
                    <P>(B) All existing, proposed, or prior exclusions and all similar actions taken by Federal, State, or local agencies, including administrative agreements that affect only those agencies;</P>
                    <P>(C) All criminal and civil proceedings not included in the notice of proposed debarment that grew out of facts relevant to the cause(s) stated in the notice; and</P>
                    <P>(D) All of the contractor's affiliates.</P>
                    <P>(ix) That if the contractor fails to disclose the information in 9.406-3(c)(3)(viii), or provides false information, the agency taking the action may seek further criminal, civil or administrative action against the contractor, as appropriate.</P>
                    <P>
                        (d) 
                        <E T="03">Suspending and debarring official's decision.</E>
                    </P>
                    <P>(1) In actions based upon a conviction or civil judgment, or in which there is no genuine dispute over material facts, the suspending and debarring official shall make a decision on the basis of all the information in the administrative record, including any submission made by the contractor. If no suspension is in effect, the decision shall be made within 45 days from the date that the official administrative record is closed, unless the suspending and debarring official extends this period for good cause. The official record closes upon the suspending and debarring official's receipt of final submissions, information and findings of fact, if any.</P>
                    <STARS/>
                    <P>
                        (e) 
                        <E T="03">Notice of suspending and debarring official's decision.</E>
                         (1) If the suspending and debarring official decides to impose debarment, the contractor and any affiliates involved shall be given prompt notice by the procedures set forth in 9.406-3(c)(1) and (2)—* * *
                    </P>
                    <P>
                        (f) 
                        <E T="03">Administrative agreements.</E>
                         (1) If the contractor enters into an administrative agreement with the Government in order to resolve a debarment or potential debarment proceeding, the suspending and debarring official shall access the website (available at 
                        <E T="03">https://www.cpars.gov,</E>
                         then select FAPIIS), enter the requested information, and upload the administrative agreement.
                    </P>
                    <P>(2) The suspending and debarring official is responsible for the timely and accurate submission of documentation reflecting the administrative agreement. The submission should be made within 3 working days.</P>
                    <P>
                        (3) With regard to information that may be covered by a disclosure 
                        <PRTPAGE P="1050"/>
                        exemption under the Freedom of Information Act, the suspending and debarring official shall follow the procedures at 9.105-2(b)(2)(iv).
                    </P>
                    <P>
                        (g) 
                        <E T="03">Voluntary exclusions.</E>
                         (1) If the contractor enters into a voluntary exclusion with the Government in order to resolve a debarment or potential debarment matter, the suspending and debarring official shall access the website (available at 
                        <E T="03">https://www.sam.gov</E>
                        ) and enter the requested information into the exclusions section of SAM (see 9.404(c)(3)).
                    </P>
                    <P>(2) The suspending and debarring official is responsible for the timely and accurate submission of documentation reflecting the voluntary exclusion. The submission should be made within 3 working days.</P>
                    <P>(3) Regarding information that may be covered by a disclosure exemption under the Freedom of Information Act, the suspending and debarring official shall follow the procedures at 9.105-2(b)(2)(iv).</P>
                    <P>
                        (h) 
                        <E T="03">Pre-notice letters.</E>
                         Prior to initiating a proposed debarment, a pre-notice letter may be issued at the discretion of the agency suspending and debarring official. A pre-notice letter is not required to initiate debarment under this subpart. (See 9.403.)
                    </P>
                </SECTION>
                <SECTION>
                    <SECTNO>9.406-4</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>15. Amend section 9.406-4 by—</AMDPAR>
                <AMDPAR>a. Removing from paragraphs (b) and (c) introductory text “The debarring official” and adding “The suspending and debarring official” in their places; and</AMDPAR>
                <AMDPAR>b. Removing from paragraph (c)(5) “the debarring official” and adding “the suspending and debarring official” in its place.</AMDPAR>
                <AMDPAR>16. Amend section 9.407-1 by—</AMDPAR>
                <AMDPAR>a. Removing from paragraph (a) “suspending official” and adding “suspending and debarring official” in its place;</AMDPAR>
                <AMDPAR>b. Revising paragraphs (b)(1) and (2);</AMDPAR>
                <AMDPAR>c. Removing from paragraph (c) introductory text “suspending official” and adding “suspending and debarring official” in its place;</AMDPAR>
                <AMDPAR>d. Revising paragraph (e)(1); and</AMDPAR>
                <AMDPAR>e. Removing from paragraph ((e)(2) “FAR and FPMR” and adding “FAR and FMR” in its place.</AMDPAR>
                <P>The revisions read as follows:</P>
                <SECTION>
                    <SECTNO>9.407-1</SECTNO>
                    <SUBJECT>General.</SUBJECT>
                    <STARS/>
                    <P>(b)(1) Suspension is a serious action to be imposed on the basis of adequate evidence, pending the completion of investigation or legal proceedings, when it has been determined that immediate action is necessary to protect the Government's interest. In deciding whether immediate action is necessary to protect the Government's interest, the suspending and debarring official has wide discretion. The suspending and debarring official may infer the necessity for immediate action to protect the Government's interest either from the nature of the circumstances giving rise to a cause for suspension or from potential business relationships or involvement with a program of the Federal Government. In assessing the adequacy of the evidence, agencies should consider how much information is available, how credible it is given the circumstances, whether or not important allegations are corroborated, and what inferences can reasonably be drawn as a result. This assessment should include an examination of basic documents such as contracts, inspection reports, and correspondence. An indictment or other official findings by Federal, State, or local bodies that determine factual and/or legal matters, constitutes adequate evidence for purposes of suspension actions.</P>
                    <P>(2) The existence of a cause for suspension does not necessarily require that the contractor be suspended. The suspending and debarring official should consider the seriousness of the contractor's acts or omissions and may, but is not required to, consider remedial measures, mitigating factors, or aggravating factors, such as those set forth in 9.406-1(a). A contractor has the burden of promptly presenting to the suspending and debarring official evidence of remedial measures or mitigating factors when it has reason to know that a cause for suspension exists. The existence or nonexistence of any remedial measures or aggravating or mitigating factors is not necessarily determinative of a contractor's present responsibility.</P>
                    <STARS/>
                    <P>(e)(1) When the suspending and debarring official has authority to suspend contractors from both acquisition contracts pursuant to this regulation and contracts for the purchase of Federal personal property pursuant to Federal Management Regulations (FMR) 41 CFR part 102-38 (see section 102-38.175), that official shall consider simultaneously suspending the contractor from the award of acquisition contracts and from the purchase of Federal personal property.</P>
                    <STARS/>
                </SECTION>
                <SECTION>
                    <SECTNO>9.407-2</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>17. Amend section 9.407-2 by removing from paragraphs (a) introductory text and (c) “The suspending official” and adding “The suspending and debarring official” in their places.</AMDPAR>
                <AMDPAR>18. Amend section 9.407-3 by—</AMDPAR>
                <AMDPAR>a. Removing from paragraph (a) “suspending official” and adding “suspending and debarring official” in its place;</AMDPAR>
                <AMDPAR>b. Adding two sentences to the end of paragraph (b)(1);</AMDPAR>
                <AMDPAR>c. Removing from paragraph (b)(2) introductory text “of Department of Justice advice, that” and adding “of advice from the Department of Justice, a U.S. Attorney's office, State attorney general's office, or a State or local prosecutor's office, that” in its place;</AMDPAR>
                <AMDPAR>d. Removing from paragraph (c) introductory text “certified mail, return receipt requested—” and adding “the procedures set forth in 9.406-3(c)(1) and (2)—” in its place;</AMDPAR>
                <AMDPAR>e. Removing from paragraph (c)(1) introductory text “irregularities” and adding “irregularities—” in its place;</AMDPAR>
                <AMDPAR>f. Removing from paragraph (c)(1)(i) “of a” and “Government or” and adding “Of a” and “Government; or” in their places, respectively;</AMDPAR>
                <AMDPAR>g. Removing from paragraph (c)(1)(ii) “seriously” and adding “Seriously” in its place;</AMDPAR>
                <AMDPAR>h. Removing from paragraph (c)(5) “facts; and” and adding “facts;” in its place;</AMDPAR>
                <AMDPAR>i. Revise paragraph (c)(6);</AMDPAR>
                <AMDPAR>j. Adding paragraphs (c)(7) and (8);</AMDPAR>
                <AMDPAR>k. Revising paragraphs (d) introductory text and (d)(1);</AMDPAR>
                <AMDPAR>l. Removing from paragraph (d)(2)(i) “suspending official” and adding “suspending and debarring official” in its place;</AMDPAR>
                <AMDPAR>m. Removing from paragraph (d)(2)(ii) “suspending official” (twice) and adding “suspending and debarring official” (twice) in their places;</AMDPAR>
                <AMDPAR>n. Removing from paragraph (d)(2)(iii) “suspending official's” and adding “suspending and debarring official's” in its place;</AMDPAR>
                <AMDPAR>o. Removing from paragraph (d)(3) introductory text “suspending official” and “imposition of” and adding “suspending and debarring official” and “imposition of—” in their places, respectively;</AMDPAR>
                <AMDPAR>p. Removing from paragraph (d)(3)(i) “suspension” and “agency or” and adding “Suspension” and “agency; or” in their places, respectively;</AMDPAR>
                <AMDPAR>q. Removing from paragraph (d)(3)(ii) “debarment” and adding “Debarment” in its place;</AMDPAR>
                <AMDPAR>r. Revising paragraph (d)(4);</AMDPAR>
                <AMDPAR>s. Revising paragraph (e)(1) and (2);</AMDPAR>
                <AMDPAR>
                    t. Removing from paragraph (e)(3) “suspending official” and adding 
                    <PRTPAGE P="1051"/>
                    “suspending and debarring official” in its place; and
                </AMDPAR>
                <AMDPAR>u. Adding paragraphs (f) and (g).</AMDPAR>
                <P>The revisions and additions read as follows:</P>
                <SECTION>
                    <SECTNO>9.407-3</SECTNO>
                    <SUBJECT>Procedures.</SUBJECT>
                    <STARS/>
                    <P>(b) * * *</P>
                    <P>(1) * * * The suspending and debarring official may use the flexible procedures in 9.406-3(b)(1). If so, the suspending and debarring official should change the notice in paragraph (c)(5) of this section to include those flexible procedures.</P>
                    <STARS/>
                    <P>(c) * * *</P>
                    <P>(6) That additional proceedings to determine disputed material facts will be conducted unless—</P>
                    <P>(i) The action is based on an indictment; or</P>
                    <P>(ii) A determination is made, on the basis of advice by the Department of Justice, a U.S. Attorney's office, State attorney general's office, or a State or local prosecutor's office, that the substantial interests of the Government in pending or contemplated legal proceedings based on the same facts as the suspension would be prejudiced;</P>
                    <P>(7) That, in addition to any information and argument in opposition to a suspension, the contractor must identify—</P>
                    <P>(i) Specific facts that contradict the statements contained in the notice of suspension. Include any information about any of the factors listed in 9.406-1(a). A general denial is insufficient to raise a genuine dispute over facts material to the suspension;</P>
                    <P>(ii) All existing, proposed, or prior exclusions and all similar actions taken by Federal, State, or local agencies, including administrative agreements that affect only those agencies;</P>
                    <P>(iii) All criminal and civil proceedings not included in the notice of suspension that grew out of facts relevant to the cause(s) stated in the notice; and</P>
                    <P>(iv) All of the contractor's affiliates; and</P>
                    <P>(8) That if the contractor fails to disclose the information in 9.407-3(c)(7), or provides false information, the agency taking the action may seek further criminal, civil or administrative action against the contractor, as appropriate.</P>
                    <P>
                        (d) 
                        <E T="03">Suspending and debarring official's decision.</E>
                         (1) The suspending and debarring official's decision shall be based on all the information in the administrative record, including any submission made by the contractor, for actions—
                    </P>
                    <P>(i) Based on an indictment;</P>
                    <P>(ii) In which the contractor's submission does not raise a genuine dispute over material facts; or</P>
                    <P>(iii) In which additional proceedings to determine disputed material facts have been denied on the basis of advice from the Department of Justice, a U.S. Attorney's office, State attorney general's office, or a State or local prosecutor's office.</P>
                    <STARS/>
                    <P>(4) Prompt written notice of the suspending and debarring official's decision shall be sent to the contractor and any affiliates involved, by the procedures set forth in 9.406-3(c)(1) and (2).</P>
                    <P>
                        (e)(1) If the contractor enters into an administrative agreement with the Government in order to resolve a suspension or potential suspension proceeding, the suspending and debarring official shall access the website (available at 
                        <E T="03">https://www.cpars.gov,</E>
                         then select FAPIIS), enter the requested information, and upload the administrative agreement.
                    </P>
                    <P>(2) The suspending and debarring official is responsible for the timely and accurate submission of documentation reflecting the administrative agreement. The submission should be made within 3 working days.</P>
                    <STARS/>
                    <P>
                        (f)(1) If the contractor enters into a voluntary exclusion with the Government in order to resolve a suspension or potential suspension proceeding, the suspending and debarring official shall access the website (available at 
                        <E T="03">https://www.sam.gov</E>
                        ) and enter the requested information into the exclusions section of SAM (see 9.404(c)(3)).
                    </P>
                    <P>(2) The suspending and debarring official is responsible for the timely and accurate submission of documentation reflecting the voluntary exclusion. The submission should be made within 3 working days.</P>
                    <P>(3) Regarding information that may be covered by a disclosure exemption under the Freedom of Information Act, the suspending and debarring official shall follow the procedures at 9.105-2(b)(2)(iv).</P>
                    <P>
                        (g) 
                        <E T="03">Pre-notice letter.</E>
                         Prior to initiating a suspension, a pre-notice letter may be issued at the discretion of the agency suspending and debarring official. A pre-notice letter is not required to initiate suspension under this subpart. (See 9.403.)
                    </P>
                </SECTION>
                <AMDPAR>19. Amend section 9.407-4 by—</AMDPAR>
                <AMDPAR>a. Removing from paragraph (a) “suspending official” and adding “suspending and debarring official” in its place;</AMDPAR>
                <AMDPAR>b. Removing from paragraph (b) “Assistant Attorney General requests” and adding “office of a U.S. Assistant Attorney General, U.S. Attorney, or other responsible prosecuting official requests” in its place; and</AMDPAR>
                <AMDPAR>c. Revising paragraph (c) to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>9.407-4</SECTNO>
                    <SUBJECT>Period of suspension.</SUBJECT>
                    <STARS/>
                    <P>(c) The suspending and debarring official shall notify the Department of Justice or other responsible prosecuting official of the proposed termination of the suspension, at least 30 days before the 12-month period expires, to give that official an opportunity to request an extension on the Government's behalf.</P>
                </SECTION>
                <SECTION>
                    <SECTNO>9.409</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>20. Amend section 9.409 by removing from the text “or Proposed for Debarment, in” and adding “Proposed for Debarment, or Voluntarily Excluded, in” in its place.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 22—APPLICATION OF LABOR LAWS TO GOVERNMENT ACQUISITIONS</HD>
                    <SECTION>
                        <SECTNO>22.1504</SECTNO>
                        <SUBJECT>[Amended]</SUBJECT>
                    </SECTION>
                </PART>
                <AMDPAR>21. Amend section 22.1504 by—</AMDPAR>
                <AMDPAR>a. Removing from paragraph (b)(2) “The suspending official” and adding “The suspending and debarring official” in its place; and</AMDPAR>
                <AMDPAR>b. Removing from paragraph (b)(3) “The debarring official” and adding “The suspending and debarring official” in its place.</AMDPAR>
                <SECTION>
                    <SECTNO>22.1704</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>22. Amend 22.1704 by removing from paragraph (c)(2)(i) introductory text “suspending or debarring” and adding “suspending and debarring” in its place.</AMDPAR>
                <AMDPAR>23. Amend section 22.1802 by revising paragraph (e) to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>22.1802</SECTNO>
                    <SUBJECT>Policy.</SUBJECT>
                    <STARS/>
                    <P>
                        (e) DHS and the Social Security Administration (SSA) may terminate a contractor's MOU and deny access to the E-Verify system in accordance with the terms of the MOU. If DHS or SSA terminates a contractor's MOU, the terminating agency must refer the contractor to a suspending and debarring official for possible suspension or debarment action. During the period between termination of the MOU and a decision by the suspending and debarring official whether to suspend or debar, the contractor is excused from its obligations under paragraph (b) of the clause at 52.222-54. If the contractor is suspended or debarred as a result of the MOU 
                        <PRTPAGE P="1052"/>
                        termination, the contractor is not eligible to participate in E-Verify during the period of its suspension, debarment, or voluntary exclusion. If the suspending and debarring official determines not to suspend, or debar, or voluntarily exclude the contractor, then the contractor must reenroll in E-Verify.
                    </P>
                </SECTION>
                <PART>
                    <HD SOURCE="HED">PART 23—ENVIRONMENT, ENERGY AND WATER EFFICIENCY, RENEWABLE ENERGY TECHNOLOGIES, OCCUPATIONAL SAFETY, AND DRUG-FREE WORKPLACE</HD>
                    <SECTION>
                        <SECTNO>23.506</SECTNO>
                        <SUBJECT>[Amended]</SUBJECT>
                    </SECTION>
                </PART>
                <AMDPAR>24. Amend section 23.506 by removing from paragraph (c) “suspension and debarment” and adding “suspending and debarring” in its place.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 25—FOREIGN ACQUISITION</HD>
                    <SECTION>
                        <SECTNO>25.206</SECTNO>
                        <SUBJECT>[Amended]</SUBJECT>
                    </SECTION>
                </PART>
                <AMDPAR>25. Amend section 25.206 by removing from paragraph (c)(4) “suspending or debarring” and “Subpart 9.4” and adding “suspending and debarring” and “subpart 9.4” in their places, respectively.</AMDPAR>
                <SECTION>
                    <SECTNO>25.607</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>26. Amend section 25.607 by removing from paragraph (c)(4) “suspending or debarring” and adding “suspending and debarring” in its place.</AMDPAR>
                <SECTION>
                    <SECTNO>25.702-3</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>27. Amend section 25.702-3 by—</AMDPAR>
                <AMDPAR>a. Removing from paragraph (b) “suspending official” and “Subpart” and adding “suspending and debarring official” and “subpart” in their places, respectively; and</AMDPAR>
                <AMDPAR>b. Removing from paragraph (c) “The debarring” and “Subpart” and adding “The suspending and debarring” and “subpart” in their places, respectively.</AMDPAR>
                <SECTION>
                    <SECTNO>25.703-2</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>28. Amend section 25.703-2 by—</AMDPAR>
                <AMDPAR>a. Removing from paragraph (b)(2) “suspending official” and adding “suspending and debarring official” in its place; and</AMDPAR>
                <AMDPAR>b. Removing from paragraph (b)(3) “The debarring official” and adding “The suspending and debarring official” in its place.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 33—PROTESTS, DISPUTES, AND APPEALS</HD>
                    <SECTION>
                        <SECTNO>33.102</SECTNO>
                        <SUBJECT>[Amended]</SUBJECT>
                    </SECTION>
                </PART>
                <AMDPAR>29. Amend section 33.102 by removing from paragraph (b)(3)(iii) “debarment official” and “Subpart” and adding “suspending and debarring official” and “subpart” in their places, respectively.</AMDPAR>
                <PART>
                    <HD SOURCE="HED">PART 52—SOLICITATION PROVISIONS AND CONTRACT CLAUSES</HD>
                </PART>
                <AMDPAR>30. Amend section 52.209-6 by—</AMDPAR>
                <AMDPAR>a. Revising the section heading and clause title;</AMDPAR>
                <AMDPAR>b. Revising the date of the clause;</AMDPAR>
                <AMDPAR>c. Removing from paragraph (c) “suspended, or proposed for debarment by” and adding “suspended, proposed for debarment, or voluntarily excluded, by” in its place;</AMDPAR>
                <AMDPAR>d. Removing from paragraph (d) introductory text “or proposed for debarment” and adding “proposed for debarment, or voluntarily excluded” in its place; and</AMDPAR>
                <AMDPAR>e. Removing from paragraph (d)(4) “suspension, or proposed debarment” and adding “suspension, proposed debarment, or voluntary exclusion” in its place.</AMDPAR>
                <P>The revision reads as follows:</P>
                <SECTION>
                    <SECTNO>52.209-6</SECTNO>
                    <SUBJECT>Protecting the Government's Interest When Subcontracting with Contractors Debarred, Suspended, Proposed for Debarment, or Voluntarily Excluded.</SUBJECT>
                    <STARS/>
                    <HD SOURCE="HD1">Protecting the Government's Interest When Subcontracting With Contractors Debarred, Suspended, Proposed for Debarment, or Voluntarily Excluded (Date)</HD>
                    <STARS/>
                </SECTION>
                <AMDPAR>31. Amend section 52.212-5 by—</AMDPAR>
                <AMDPAR>a. Revising the date of the clause;</AMDPAR>
                <AMDPAR>b. Revising paragraph (b)(12);</AMDPAR>
                <AMDPAR>c. Revising the date of paragraphs (b)(32) and (40);</AMDPAR>
                <AMDPAR>d. Revising the date of paragraph (e)(1)(xix); and</AMDPAR>
                <AMDPAR>e. Amend Alternate II by revising the date of Alternate II and paragraph (R).</AMDPAR>
                <P>The revisions read as follows:</P>
                <SECTION>
                    <SECTNO>52.212-5</SECTNO>
                    <SUBJECT>Contract Terms and Conditions Required To Implement Statutes or Executive Orders-Commercial Products and Commercial Services.</SUBJECT>
                    <STARS/>
                    <HD SOURCE="HD1">Contract Terms and Conditions Required To Implement Statutes or Executive Orders-Commercial Products and Commercial Services (Date)</HD>
                    <STARS/>
                    <P>(b) * * *</P>
                    <P>__(12) 52.209-6, Protecting the Government's Interest When Subcontracting with Contractors Debarred, Suspended, Proposed for Debarment, or Voluntarily Excluded. (Date)(31 U.S.C. 6101 note).</P>
                    <STARS/>
                    <P>__(32) 52.222-19, Child Labor-Cooperation with Authorities and Remedies (Date) (E.O. 13126).</P>
                    <STARS/>
                    <P>__(40) 52.222-54, Employment Eligibility Verification (Date). (Executive Order 12989). (Not applicable to the acquisition of commercially available off-the-shelf items or certain other types of commercial products or commercial services as prescribed in FAR 22.1803.)</P>
                    <STARS/>
                    <P>(e)(1) * * *</P>
                    <P>(xix) 52.222-54, Employment Eligibility Verification (Date) (E.O. 12989).</P>
                    <STARS/>
                    <P>
                        <E T="03">Alternate II.</E>
                         (Date) * * *
                    </P>
                    <P>(e)(1) * * *</P>
                    <P>(ii) * * *</P>
                    <P>(R) 52.222-54, Employment Eligibility Verification (Date) (Executive Order 12989).</P>
                    <STARS/>
                </SECTION>
                <AMDPAR>32. Amend section 52.213-4 by—</AMDPAR>
                <AMDPAR>a. Revising the date of the clause;</AMDPAR>
                <AMDPAR>b. Revising the date of paragraph (b)(1)(iii) and removing “in 2.101” and adding “in FAR 2.101” in its place; and</AMDPAR>
                <AMDPAR>c. Removing from paragraph (b)(2)(ii) “or Proposed for Debarment (NOV 2021)” and adding “Proposed for Debarment, or Voluntarily Excluded (Date)” in its place.</AMDPAR>
                <P>The revisions read as follows:</P>
                <SECTION>
                    <SECTNO>52.213-4</SECTNO>
                    <SUBJECT>Terms and Conditions—Simplified Acquisitions (Other Than Commercial Products and Commercial Services).</SUBJECT>
                    <STARS/>
                    <HD SOURCE="HD1">Terms and Conditions—Simplified Acquisitions (Other Than Commercial Products and Commercial Services) ([Date)</HD>
                    <STARS/>
                    <P>(b) * * *</P>
                    <P>(1) * * *</P>
                    <P>(iii) 52.222-19, Child Labor—Cooperation with Authorities and Remedies (Date) * * *</P>
                    <STARS/>
                </SECTION>
                <AMDPAR>33. Amend section 52.222-19 by—</AMDPAR>
                <AMDPAR>a. Revising the date of the clause;</AMDPAR>
                <AMDPAR>b. Removing from paragraph (d)(2) “suspending official” and “Subpart” and adding “suspending and debarring official” and “subpart” in their places, respectively; and</AMDPAR>
                <AMDPAR>c. Removing from paragraph (d)(3) “The debarring” and “Subpart” and adding “The suspending and debarring” and “subpart” in their places, respectively.</AMDPAR>
                <P>The revision reads as follows:</P>
                <SECTION>
                    <SECTNO>52.222-19</SECTNO>
                    <SUBJECT>Child Labor—Cooperation with Authorities and Remedies.</SUBJECT>
                    <STARS/>
                    <PRTPAGE P="1053"/>
                    <HD SOURCE="HD1">Child Labor—Cooperation With Authorities and Remedies (Date)</HD>
                    <STARS/>
                </SECTION>
                <AMDPAR>34. Amend section 52.222-54 by—</AMDPAR>
                <AMDPAR>a. Revising the date of the clause;</AMDPAR>
                <AMDPAR>b. Removing from paragraph (b)(5)(i) “suspension or debarment” and adding “suspending and debarring” in its place; and</AMDPAR>
                <AMDPAR>c. Revising paragraph (b)(5)(ii).</AMDPAR>
                <P>The revisions read as follows:</P>
                <SECTION>
                    <SECTNO>52.222-54</SECTNO>
                    <SUBJECT>Employment Eligibility Verification.</SUBJECT>
                    <STARS/>
                    <HD SOURCE="HD1">Employment Eligibility Verification (Date)</HD>
                    <STARS/>
                    <P>(b) * * *</P>
                    <P>(5) * * *</P>
                    <P>(ii) During the period between termination of the MOU and a decision by the suspending and debarring official whether to suspend or debar, the Contractor is excused from its obligations under paragraph (b) of this clause. If the suspending and debarring official determines not to suspend, debar, or voluntarily exclude the Contractor, then the Contractor must reenroll in E-Verify.</P>
                    <STARS/>
                </SECTION>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00172 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6820-EP-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Motor Carrier Safety Administration</SUBAGY>
                <CFR>49 CFR Part 367</CFR>
                <DEPDOC>[Docket No. FMCSA-2023-0268 RIN 2126-AC67]</DEPDOC>
                <SUBJECT>Fees for the Unified Carrier Registration Plan and Agreement</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 of proposed rulemaking (NPRM).</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>FMCSA proposes amendments to its regulations governing the annual registration fees that participating States collect from motor carriers, motor private carriers of property, brokers, freight forwarders, and leasing companies for the Unified Carrier Registration (UCR) Plan and Agreement for the 2025 registration year and subsequent registration years. The fees for the 2025 registration year would be increased above the fees for the 2024 registration year by an average of 25.0 percent overall, with varying increases between $9 and $9,000 per entity, depending on the applicable fee bracket. The proposal is based upon a recommendation from the UCR Plan.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received on or before February 8, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments identified by Docket Number FMCSA-2023-0268 using any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal:</E>
                         Go to 
                        <E T="03">https://www.regulations.gov/docket/FMCSA-2023-0268/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>
                        Mr. Kenneth Riddle, Director, Office of Registration and Safety Information, FMCSA, 1200 New Jersey Avenue SE, Washington, DC 20590-0001, 
                        <E T="03">FMCSAMCRS@dot.gov.</E>
                         If you have questions on viewing or submitting material to the docket, call Dockets Operations at (202) 366-9826.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>FMCSA organizes this NPRM 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</FP>
                    <FP SOURCE="FP-2">II. Executive Summary</FP>
                    <FP SOURCE="FP1-2">A. Purpose and Summary of the Regulatory Action</FP>
                    <FP SOURCE="FP1-2">B. Costs and Benefits</FP>
                    <FP SOURCE="FP-2">III. Abbreviations</FP>
                    <FP SOURCE="FP-2">IV. Legal Basis</FP>
                    <FP SOURCE="FP-2">V. Background</FP>
                    <FP SOURCE="FP-2">VI. Discussion of Proposed Rulemaking</FP>
                    <FP SOURCE="FP-2">VII. Severability</FP>
                    <FP SOURCE="FP-2">VIII. Section-by-Section Analysis</FP>
                    <FP SOURCE="FP-2">IX. Regulatory Analyses</FP>
                    <FP SOURCE="FP1-2">A. Executive Order (E.O.) 12866 (Regulatory Planning and Review), E.O. 13563 (Improving Regulation and Regulatory Review), E.O. 14094 (Modernizing Regulatory Review), and DOT Regulatory Policies and Procedures</FP>
                    <FP SOURCE="FP1-2">B. Congressional Review Act</FP>
                    <FP SOURCE="FP1-2">C. Regulatory Flexibility Act</FP>
                    <FP SOURCE="FP1-2">D. Assistance for Small Entities</FP>
                    <FP SOURCE="FP1-2">E. Unfunded Mandates Reform Act of 1995</FP>
                    <FP SOURCE="FP1-2">F. Paperwork Reduction Act</FP>
                    <FP SOURCE="FP1-2">G. E.O. 13132 (Federalism)</FP>
                    <FP SOURCE="FP1-2">H. Privacy</FP>
                    <FP SOURCE="FP1-2">I. E.O. 13175 (Indian Tribal Governments)</FP>
                    <FP SOURCE="FP1-2">J. National Environmental Policy Act of 1969</FP>
                    <FP SOURCE="FP1-2">K. Rulemaking Summary</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. Public Participation and Request for Comments</HD>
                <HD SOURCE="HD2">A. Submitting Comments</HD>
                <P>If you submit a comment, please include the docket number for this NPRM (FMCSA-2023-0268), 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-2023-0268/document,</E>
                     click on this NPRM, 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 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 the NPRM, 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 NPRM. Submissions containing CBI should be sent to Mr. 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, 
                    <PRTPAGE P="1054"/>
                    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 rulemaking.
                </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-2023-0268/document</E>
                     and choose the document to review. To view comments, click this NPRM, 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</HD>
                <P>
                    DOT solicits comments from the public to better inform its regulatory process, in accordance with 5 U.S.C. 553(c). DOT posts these comments, including any personal information the commenter provides, to 
                    <E T="03">www.regulations.gov.</E>
                     This process is 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. Executive Summary</HD>
                <HD SOURCE="HD2">A. Purpose and Summary of the Regulatory Action</HD>
                <P>Under 49 U.S.C. 14504a, the UCR Plan and the 41 States participating in the UCR Agreement collect fees from motor carriers, motor private carriers of property, brokers, freight forwarders, and leasing companies. The UCR Plan and Agreement are administered by a 15-member board of directors (UCR Plan Board), which is comprised of 14 members appointed from the participating States and the industry, and the Deputy Administrator of FMCSA, who is a statutory member. Revenues collected are allocated to the participating States and the UCR Plan.</P>
                <P>
                    In accordance with 49 U.S.C. 14504a(d)(7) and (f)(1)(E)(ii), the UCR Plan provides fee adjustment recommendations to the Secretary when revenue collections result in a shortfall or surplus from the amount authorized by statute. If the required payments to the States and the cost of administering the UCR Plan exceed the amount in the depository, the UCR Plan must collect additional fees in subsequent years to cover the shortfall. If there are excess funds after payments to the States and for administrative costs, they are retained in the UCR Plan's depository, and fees in subsequent fee years must be reduced as required by 49 U.S.C. 14504a(h)(4). These two distinct statutory provisions are recognized in the fee adjustment recommended by the UCR Plan and proposed in this NPRM, to increase by an average of 25.0 percent the annual registration fees established pursuant to the UCR Agreement for the 2025 registration year and subsequent years.
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         The UCR Plan Board's recommendation (September 2023 Fee Recommendation) was issued on September 27, 2023, and is available in the docket for this rulemaking.
                    </P>
                </FTNT>
                <HD SOURCE="HD2">B. Costs and Benefits</HD>
                <P>The changes proposed in this NPRM would increase the fees paid by motor carriers, motor private carriers of property, brokers, freight forwarders, and leasing companies to the UCR Plan and the participating States. While each motor carrier or other covered entity might realize an increased burden, fees are considered by the Office of Management and Budget (OMB) Circular A-4, Regulatory Analysis, as transfer payments, not costs. Transfer payments are payments from one group to another that do not affect total resources available to society. Therefore, transfers are not considered in the monetization of societal costs and benefits of rulemakings. The details of the amount of increase to the annual UCR fee for each fee bracket, are included in the discussion below in Section VI.</P>
                <HD SOURCE="HD1">III. Abbreviations</HD>
                <EXTRACT>
                    <FP SOURCE="FP-1">CBI Confidential Business Information</FP>
                    <FP SOURCE="FP-1">CFR Code of Federal Regulations</FP>
                    <FP SOURCE="FP-1">CMV Commercial Motor Vehicle</FP>
                    <FP SOURCE="FP-1">DOT Department of Transportation</FP>
                    <FP SOURCE="FP-1">E.O. Executive Order</FP>
                    <FP SOURCE="FP-1">FMCSA Federal Motor Carrier Safety Administration</FP>
                    <FP SOURCE="FP-1">FR Federal Register</FP>
                    <FP SOURCE="FP-1">NAICS North American Industry Classification System</FP>
                    <FP SOURCE="FP-1">NPRM Notice of Proposed Rulemaking</FP>
                    <FP SOURCE="FP-1">OMB Office of Management and Budget</FP>
                    <FP SOURCE="FP-1">PIA Privacy Impact Assessment</FP>
                    <FP SOURCE="FP-1">PTA Privacy Threshold Assessment</FP>
                    <FP SOURCE="FP-1">RFA Regulatory Flexibility Act</FP>
                    <FP SOURCE="FP-1">SBA Small Business Administration</FP>
                    <FP SOURCE="FP-1">SBREFA Small Business Regulatory Enforcement Fairness Act of 1996 Secretary Secretary of Transportation</FP>
                    <FP SOURCE="FP-1">UCR Unified Carrier Registration</FP>
                    <FP SOURCE="FP-1">UMRA Unfunded Mandates Reform Act</FP>
                    <FP SOURCE="FP-1">U.S.C. United States Code</FP>
                </EXTRACT>
                <HD SOURCE="HD1">IV. Legal Basis</HD>
                <P>This rulemaking would adjust the annual UCR registration fees, as authorized by 49 U.S.C. 14504a. Section 14504a provides that the revenues collected from the fees should not exceed the maximum annual revenue entitlements distributed to the 41 participating States plus the amount established for administrative costs associated with the UCR Plan and Agreement. In accordance with 49 U.S.C. 14504a(f)(1)(E)(i), the statute provides for the UCR Plan to request an adjustment by the Secretary of Transportation (the Secretary) when the annual revenues are insufficient to provide the revenues to which the participating States are entitled.</P>
                <P>In addition, 49 U.S.C. 14504a(h)(4) states that any excess funds from previous registration years held by the UCR Plan in its depository, after distribution to the States and for payment of administrative costs, shall be retained and the fees charged shall be reduced by the Secretary accordingly (49 U.S.C. 14504a(h)(4)).</P>
                <P>The UCR Plan must also obtain DOT approval to revise the total revenue to be collected, in accordance with 49 U.S.C. 14504a(d)(7). However, no changes in the revenue allocations to the participating States were recommended by the UCR Plan or would be authorized by this rulemaking.</P>
                <P>The Secretary also has broad rulemaking authority in 49 U.S.C. 13301(a) to carry out 49 U.S.C. 14504a, which is part of 49 U.S.C. subtitle IV, part B. Authority to administer these statutory provisions has been delegated to the FMCSA Administrator by 49 CFR 1.87(a)(2) and (7).</P>
                <HD SOURCE="HD1">V. Background</HD>
                <P>
                    This NPRM follows UCR adjustments for prior two registration years that, collectively, reduced fees by an aggregate average of 37.3 percent. First, the 2022 final rule (Fees for the Unified Carrier Registration Plan and Agreement, Sept. 1, 2022 (87 FR 53680)), as corrected on September 8, 2022 (87 FR 54902) reduced the fees for 2023 by an average of 31.2 percent from the fees for 2022. The following year, the 2023 final rule (Fees for the Unified Carrier Registration Plan and Agreement, June 22, 2023 (88 FR 40719)) reduced the fees for 2024 by an additional average of 8.9 percent from the fees for 2023. Both fee adjustment recommendations submitted by the UCR Plan, and particularly the 2023 
                    <PRTPAGE P="1055"/>
                    recommendation (for 2024 registration year fees), explicitly anticipated a need to increase fees in, or around, the 2025 fee registration year because the funds from excess collections that required the 2 years of fee reductions, would be largely utilized. This need for registration fee adjustments is unavoidable due to both the statutory requirements for the UCR Plan and Agreement (as discussed above) and the fluctuations in the number of entities registering with the Plan.
                </P>
                <P>The fee levels, actual and proposed, for the registration years 2019 to 2025 are shown in the following table:</P>
                <GPOTABLE COLS="7" OPTS="L2,i1" CDEF="s50,14,10,10,10,10,10">
                    <TTITLE>Table 1—UCR Plan Fees—2019-2025</TTITLE>
                    <BOXHD>
                        <CHED H="1">Bracket</CHED>
                        <CHED H="1">Number of CMVs</CHED>
                        <CHED H="1">2019</CHED>
                        <CHED H="1">2020-2022</CHED>
                        <CHED H="1">2023</CHED>
                        <CHED H="1">2024</CHED>
                        <CHED H="1">2025</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>* 0-2</ENT>
                        <ENT>$68</ENT>
                        <ENT>$59</ENT>
                        <ENT>$41</ENT>
                        <ENT>$37</ENT>
                        <ENT>$46</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>3-5</ENT>
                        <ENT>204</ENT>
                        <ENT>176</ENT>
                        <ENT>121</ENT>
                        <ENT>111</ENT>
                        <ENT>138</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>6-20</ENT>
                        <ENT>407</ENT>
                        <ENT>351</ENT>
                        <ENT>242</ENT>
                        <ENT>221</ENT>
                        <ENT>276</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>21-100</ENT>
                        <ENT>1,420</ENT>
                        <ENT>1,224</ENT>
                        <ENT>844</ENT>
                        <ENT>769</ENT>
                        <ENT>963</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>101-1000</ENT>
                        <ENT>6,766</ENT>
                        <ENT>5,835</ENT>
                        <ENT>4,024</ENT>
                        <ENT>3,670</ENT>
                        <ENT>4,592</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>1001+</ENT>
                        <ENT>66,072</ENT>
                        <ENT>56,977</ENT>
                        <ENT>39,289</ENT>
                        <ENT>35,836</ENT>
                        <ENT>44,836</ENT>
                    </ROW>
                    <TNOTE>* Also applies to brokers and leasing companies.</TNOTE>
                </GPOTABLE>
                <P>The proposed fees for 2025 are still less than the fees that were in effect in registration years 2019-2022.</P>
                <P>On September 27, 2023, the UCR Plan recommended to the Secretary that FMCSA increase the fees for the 2025 registration year no later than September 1, 2024, to allow collections to begin on October 1, 2024. As noted above, the recommendation and supporting documents are available in the docket for this rulemaking. In addition to the fee recommendation information from the UCR Plan, the submission also included an explanation of the basis for the recommendation and the procedures the UCR Plan followed in its development. This fee recommendation also included an explanation of the methodology used when calculating the fee, to facilitate public comment and allow replication of the analysis in the UCR Plan's recommendation.</P>
                <HD SOURCE="HD1">VI. Discussion of Proposed Rulemaking</HD>
                <P>This NPRM proposes to increase fees by an average of 25.0 percent for the 2025 registration year, compared to the fees for 2024. The proposed increase for each fee bracket is shown in the following table:</P>
                <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s50,15,12,12,12">
                    <TTITLE>Table 2—UCR Plan Fees Proposed Increase From 2024 to 2025</TTITLE>
                    <BOXHD>
                        <CHED H="1">Bracket</CHED>
                        <CHED H="1">Number of CMVs</CHED>
                        <CHED H="1">2024</CHED>
                        <CHED H="1">2025</CHED>
                        <CHED H="1">Difference</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>* 0-2</ENT>
                        <ENT>$37</ENT>
                        <ENT>$46</ENT>
                        <ENT>$9</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>3-5</ENT>
                        <ENT>111</ENT>
                        <ENT>138</ENT>
                        <ENT>27</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>6-20</ENT>
                        <ENT>221</ENT>
                        <ENT>276</ENT>
                        <ENT>55</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>21-100</ENT>
                        <ENT>769</ENT>
                        <ENT>963</ENT>
                        <ENT>194</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>101-1000</ENT>
                        <ENT>3,670</ENT>
                        <ENT>4,592</ENT>
                        <ENT>922</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>1001+</ENT>
                        <ENT>35,836</ENT>
                        <ENT>44,836</ENT>
                        <ENT>9,000</ENT>
                    </ROW>
                    <TNOTE>* Also applies to brokers and leasing companies.</TNOTE>
                </GPOTABLE>
                <P>
                    This upward fee adjustment, which follows significant fee reductions, had been anticipated and was discussed in the previous rulemaking addressing fee adjustments for the 2024 registration year.
                    <SU>2</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         The 2024 Fees for the Unified Carrier Registration Plan and Agreement final rule was published on June 2023 (88 FR 40719).
                    </P>
                </FTNT>
                <P>
                    The UCR Plan modified its methodology for developing the recommendation from its most recent recommendations,
                    <SU>3</SU>
                    <FTREF/>
                     as the previous methodology using average collections was determined by the UCR Plan to result in an over-collection of fees. The UCR Plan's recommendation now uses the minimum of the historical monthly collections for the same time periods in each of the prior 3-year periods to determine projected collections, which the UCR Plan believes will yield a more accurate result. This change in the methodology is explained more fully in the UCR Plan's recommendation, which is available in the docket for this rulemaking.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         As explained on page 3 of the 2025 Fee Change Proposal submitted by the UCR Plan, this change in its Fee Recommendation Policy was adopted by the board of directors of the Plan at its meeting of July 27, 2023. See also 27Jul23 
                        <E T="03">Board Minutes.pdf</E>
                         (
                        <E T="03">prod-public-ucr-docs-board-minutes.s3.amazonaws.com</E>
                        ).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">VII. Severability</HD>
                <P>The revised and new sections are not severable. This is so because if the increased fees for 2025 are set aside, then the existing fee levels must remain in effect to provide funds towards participating States receiving their revenue entitlements during 2025. While the 2024 fees would not be sufficient to fully cover the 2025 State entitlements and administrative costs, that revenue would be necessary to provide at least some portion of the entitlements due to participating States.</P>
                <HD SOURCE="HD1">VIII. Section-by-Section Analysis</HD>
                <P>FMCSA proposes to revise 49 CFR 367.40 (which was adopted in the 2023 final rule) so that the fees apply to registration year 2024 only. A new § 367.50 proposes to establish new increased fees applicable beginning in registration year 2025, based on the recommendation submitted by the UCR Plan in its September 2023 Fee Recommendation. The fees in proposed new § 367.50 would remain in effect for subsequent registration years after 2025 unless revised by a future rulemaking.</P>
                <P>
                    FMCSA also proposes to remove 49 CFR 367.20, which set the fees for 2020, 2021 and 2022, as those fee amounts will not be necessary.
                    <PRTPAGE P="1056"/>
                </P>
                <HD SOURCE="HD1">IX. Regulatory Analyses</HD>
                <HD SOURCE="HD2">A. Executive Order (E.O.) 12866 (Regulatory Planning and Review), E.O. 13563 (Improving Regulation and Regulatory Review), E.O. 14094 (Modernizing Regulatory Review), and DOT Regulatory Policies and Procedures</HD>
                <P>FMCSA has considered the impact of this NPRM under E.O. 12866 (58 FR 51735, Oct. 4, 1993), Regulatory Planning and Review, E.O. 13563 (76 FR 3821, Jan. 21, 2011), Improving Regulation and Regulatory Review, E.O. 14094 (88 FR 29179, Apr. 11, 2023) Modernizing Regulatory Review, and DOT's regulatory policies and procedures. The Office of Information and Regulatory Affairs, as stated in section 3(f) of E.O. 12866, as supplemented by E.O. 13563 and amended by E.O. 14094, does not require an assessment of potential costs and benefits under section 6(a)(3) of that order. Accordingly, OMB has not reviewed it under that E.O.</P>
                <P>The changes proposed by this rule would increase the registration fees paid by motor carriers, motor private carriers of property, brokers, freight forwarders, and leasing companies to the UCR Plan and the participating States. While each motor carrier or other entity would incur an increased burden, fees are considered by OMB Circular A-4, Regulatory Analysis, as transfer payments, not costs. Transfer payments are payments from one group to another that do not affect total resources available to society. By definition, transfers are not considered in the monetization of societal costs and benefits of rulemakings. The details of the amount of increase to the annual UCR fee for each fee bracket, are included in the discussion above in Section VI.</P>
                <P>This rulemaking would establish increases in the annual registration fees for the UCR Plan and Agreement. The entities affected by this rule are the participating States, motor carriers, motor private carriers of property, brokers, freight forwarders, and leasing companies. Because the State UCR revenue entitlements would remain unchanged, the participating States would not be impacted by this rule. The primary impact of this rule would be an increase in fees paid by individual motor carriers, motor private carriers of property, brokers, freight forwarders, and leasing companies. The increase in fees for the 2025 registration year from the 2024 registration year fees (approved on June 22, 2023 (88 FR 40179)) would be an average of 25.0 percent, ranging from $9 to $9,000 per entity, depending on the number of vehicles owned or operated by the affected entities.</P>
                <HD SOURCE="HD2">B. Congressional Review Act</HD>
                <P>
                    This rule is not a 
                    <E T="03">major rule</E>
                     as defined under the Congressional Review Act (5 U.S.C. 801-808).
                    <SU>4</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         A 
                        <E T="03">major rule</E>
                         means any rule that OMB finds has resulted in or is likely to result in (a) an annual effect on the economy of $100 million or more; (b) a major increase in costs or prices for consumers, individual industries, geographic regions, Federal, State, or local government agencies; or (c) significant adverse effects on competition, employment, investment, productivity, innovation, or on the ability of United States-based enterprises to compete with foreign-based enterprises in domestic and export markets (5 U.S.C. 802(4)).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">C. Regulatory Flexibility Act</HD>
                <P>
                    The Regulatory Flexibility Act (5 U.S.C. 601 
                    <E T="03">et seq.,</E>
                     RFA), as amended by the Small Business Regulatory Enforcement Fairness Act of 1996 (SBREFA),
                    <SU>5</SU>
                    <FTREF/>
                     requires Federal agencies to consider the effects of the regulatory action on small business and other small entities and to minimize any significant economic impact. The term 
                    <E T="03">small entities</E>
                     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 (5 U.S.C. 601(6)). Accordingly, DOT policy requires an analysis of the impact of all regulations on small entities, and mandates that agencies strive to lessen any adverse effects on these businesses.
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         Public Law 104-121, 110 Stat. 857, (Mar. 29, 1996).
                    </P>
                </FTNT>
                <P>This rulemaking would directly affect the participating States, motor carriers, motor private carriers of property, brokers, freight forwarders, and leasing companies. Under the standards of the RFA, as amended by SBREFA, the participating States are not small entities. States are not considered small entities because they do not meet the definition of a small entity in section 601 of the RFA. Specifically, States are not considered small governmental jurisdictions under section 601(5) of the RFA, both because State government is not included among the various levels of government listed in section 601(5), and because, even if this were the case, no State or the District of Columbia has a population of less than 50,000, which is the criterion by which a governmental jurisdiction is considered small under section 601(5) of the RFA.</P>
                <P>The Small Business Administration's (SBA's) size standard for a small entity (13 CFR 121.201) differs by industry code. The entities affected by this rule fall into many different industry codes. In order to determine if this rule would have an impact on a significant number of small entities, FMCSA examined the 2012 and 2017 Economic Census data for two different North American Industry Classification System (NAICS) industries: Truck Transportation (subsector 484) and Transit and Ground Transportation (subsector 485).</P>
                <P>
                    As shown in the table below, the SBA size standards for the national industries under the Truck Transportation and Transit and Ground Transportation subsectors range from $19.0 million to $43.0 million in revenue per year. To determine the percentage of firms that have revenue at or below SBA's thresholds within each of the NAICS national industries, FMCSA examined data from the 2017 Economic Census.
                    <SU>6</SU>
                    <FTREF/>
                     In instances where 2017 data were suppressed, the Agency imputed 2017 levels using data from the 2012 Economic Census.
                    <SU>7</SU>
                    <FTREF/>
                     Boundaries for the revenue categories used in the economic Census do not exactly coincide with the SBA thresholds. Instead, the SBA threshold generally falls between two different revenue categories. However, FMCSA was able to make reasonable estimates as to the percentage of small entities within each NAICS code.
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         U.S. Census Bureau. 
                        <E T="03">2017 Economic Census.</E>
                         Table EC1700SIZEEMPFIRM—Selected Sectors: Employment Size of Firms for the U.S.: 2017. Available at: 
                        <E T="03">https://www.census.gov/data/tables/2017/econ/economic-census/naics-sector-48-49.html</E>
                         (accessed Dec. 5, 2023).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         U.S. Census Bureau. 
                        <E T="03">2012 Economic Census.</E>
                         Table EC1248SSSZ4—Transportation and Warehousing: Subject Series—Estab &amp; Firm Size: Summary Statistics by Revenue Size of Firms for the U.S.: 2012 Available at: 
                        <E T="03">https://www.census.gov/data/tables/2012/econ/census/transportation-warehousing.html</E>
                         (accessed Dec. 5, 2023).
                    </P>
                </FTNT>
                <P>
                    The percentages of small entities with annual revenue less than the SBA's threshold ranged from 96.3 percent to 100 percent. Specifically, approximately 96.3 percent of Specialized Freight (except Used Goods) Trucking, Long Distance (484230) firms had annual revenue less than the SBA's revenue threshold of $34.0 million and would be considered small entities. FMCSA estimates 100 percent of firms in the Mixed Mode Transit Systems (485111) national industry had annual revenue less than $29.0 million and would be considered small entities. The table below shows the complete estimates of the number of small entities within the national industries that may be affected by this rule.
                    <PRTPAGE P="1057"/>
                </P>
                <GPOTABLE COLS="6" OPTS="L2,nj,i1" CDEF="s25,r75,10,10,10,10">
                    <TTITLE>Table 3—Estimates of Number of Small Entities</TTITLE>
                    <BOXHD>
                        <CHED H="1">NAICS code</CHED>
                        <CHED H="1">Description</CHED>
                        <CHED H="1">
                            SBA size
                            <LI>standard</LI>
                            <LI>in millions</LI>
                        </CHED>
                        <CHED H="1">
                            Total
                            <LI>number</LI>
                            <LI>of firms</LI>
                        </CHED>
                        <CHED H="1">
                            Number
                            <LI>of small</LI>
                            <LI>entities</LI>
                        </CHED>
                        <CHED H="1">
                            Percent
                            <LI>of all</LI>
                            <LI>firms</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">484110</ENT>
                        <ENT>General Freight Trucking, Local</ENT>
                        <ENT>$34.0</ENT>
                        <ENT>22,066</ENT>
                        <ENT>21,950</ENT>
                        <ENT>99.5</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">484121</ENT>
                        <ENT>General Freight Trucking, Long Distance, Truckload</ENT>
                        <ENT>34.0</ENT>
                        <ENT>23,557</ENT>
                        <ENT>23,045</ENT>
                        <ENT>97.8</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">484122</ENT>
                        <ENT>General Freight Trucking, Long Distance, Less Than Truckload</ENT>
                        <ENT>43.0</ENT>
                        <ENT>3,138</ENT>
                        <ENT>3,050</ENT>
                        <ENT>97.2</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">484210</ENT>
                        <ENT>Used Household and Office Goods Moving</ENT>
                        <ENT>34.0</ENT>
                        <ENT>6,097</ENT>
                        <ENT>6,041</ENT>
                        <ENT>99.1</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">484220</ENT>
                        <ENT>Specialized Freight (except Used Goods) Trucking, Local</ENT>
                        <ENT>34.0</ENT>
                        <ENT>22,797</ENT>
                        <ENT>22,631</ENT>
                        <ENT>99.3</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">484230</ENT>
                        <ENT>Specialized Freight (except Used Goods) Trucking, Long Distance</ENT>
                        <ENT>34.0</ENT>
                        <ENT>7,310</ENT>
                        <ENT>7,042</ENT>
                        <ENT>96.3</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">485111</ENT>
                        <ENT>Mixed Mode Transit Systems</ENT>
                        <ENT>29.0</ENT>
                        <ENT>25</ENT>
                        <ENT>25</ENT>
                        <ENT>100.0</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">485113</ENT>
                        <ENT>Bus and Other Motor Vehicle Transit Systems</ENT>
                        <ENT>32.5</ENT>
                        <ENT>318</ENT>
                        <ENT>308</ENT>
                        <ENT>96.9</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">485210</ENT>
                        <ENT>Interurban and Rural Bus Transportation</ENT>
                        <ENT>32.0</ENT>
                        <ENT>309</ENT>
                        <ENT>302</ENT>
                        <ENT>97.7</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">485320</ENT>
                        <ENT>Limousine Service</ENT>
                        <ENT>19.0</ENT>
                        <ENT>3,706</ENT>
                        <ENT>3,694</ENT>
                        <ENT>99.7</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">485410</ENT>
                        <ENT>School and Employee Bus Transportation</ENT>
                        <ENT>30.0</ENT>
                        <ENT>2,279</ENT>
                        <ENT>2,226</ENT>
                        <ENT>97.7</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">485510</ENT>
                        <ENT>Charter Bus Industry</ENT>
                        <ENT>19.0</ENT>
                        <ENT>1,031</ENT>
                        <ENT>1,013</ENT>
                        <ENT>98.3</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">485991</ENT>
                        <ENT>Special Needs Transportation</ENT>
                        <ENT>19.0</ENT>
                        <ENT>2,592</ENT>
                        <ENT>2,567</ENT>
                        <ENT>99.1</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">485999</ENT>
                        <ENT>All Other Transit and Ground Passenger Transportation</ENT>
                        <ENT>19.0</ENT>
                        <ENT>1,071</ENT>
                        <ENT>1,059</ENT>
                        <ENT>98.9</ENT>
                    </ROW>
                </GPOTABLE>
                <P>Therefore, while FMCSA has determined that this rulemaking would impact a substantial number of small entities, it has also determined that the rulemaking would not have a significant impact on them. The effect of this rulemaking would be to increase the annual registration fee that motor carriers, motor private carriers of property, brokers, freight forwarders, and leasing companies are currently required to pay. The increase will be 25.0 percent on average, $9 to $9,000 per entity, depending on the number of vehicles owned and/or operated by the affected entities.</P>
                <P>While the RFA does not define a threshold for determining whether a specific regulation results in a significant impact, the SBA, in guidance to government agencies, provides some objective measures of significance that the agencies can consider using. One measure that could be used to illustrate a significant impact is labor costs; specifically, whether the cost of the regulation exceeds 1 percent of the average annual revenues of small entities in the sector. Given that entities owning between 0 and 2 CMVs would experience an increase of $9, a small entity would need to have average annual revenue of less than $900 to experience an impact greater than 1 percent of average annual revenue. This is an average annual revenue that is smaller than would be required for a firm to support one employee. The increased fee amount and impact on revenue increase linearly depending on the applicable fee bracket.</P>
                <P>Consequently, I certify that the proposed action would not have a significant economic impact on a substantial number of small entities.</P>
                <HD SOURCE="HD2">D. Assistance for Small Entities</HD>
                <P>
                    In accordance with section 213(a) of SBREFA, FMCSA wants to assist small entities in understanding this proposed rule so they can better evaluate its effects on themselves and participate in the rulemaking initiative. If the proposed rule would affect your small business, organization, or governmental jurisdiction and you have questions concerning its provisions or options for compliance, please consult the person listed under 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                    . Small businesses may send comments on the actions of Federal employees who enforce or otherwise determine compliance with Federal regulations to SBA's Small Business and Agriculture Regulatory Enforcement Ombudsman (Office of the National Ombudsman, see 
                    <E T="03">https://www.sba.gov/about-sba/oversight-advocacy/office-national-ombudsman</E>
                    ) and the Regional Small Business Regulatory Fairness Boards. The Ombudsman evaluates these actions annually and rates each agency's responsiveness to small business. If you wish to comment on actions by employees of FMCSA, call 1-888-REG-FAIR (1-888-734-3247). DOT has a policy regarding the rights of small entities to regulatory enforcement fairness and an explicit policy against retaliation for exercising these rights.
                </P>
                <HD SOURCE="HD2">E. Unfunded Mandates Reform Act of 1995</HD>
                <P>The Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1531-1538, UMRA) requires Federal agencies to assess the effects of their discretionary regulatory actions. The Act addresses actions that may result in the expenditure by a State, local, or Tribal government, in the aggregate, or by the private sector of $192 million (which is the value equivalent of $100 million in 1995, adjusted for inflation to 2022 levels) or more in any 1 year. Though this NPRM would not result in such an expenditure, and the analytical requirements of UMRA do not apply as a result, the Agency discusses the effects of this rule elsewhere in this preamble.</P>
                <HD SOURCE="HD2">F. Paperwork Reduction Act</HD>
                <P>This proposed rule contains no new information collection requirements under the Paperwork Reduction Act of 1995 (44 U.S.C. 3501-3520).</P>
                <HD SOURCE="HD2">G. E.O. 13132 (Federalism)</HD>
                <P>A rule has implications for federalism under section 1(a) of E.O. 13132 if it has “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>
                <P>FMCSA has determined that this rule would not have substantial direct costs on or for States, nor would it limit the policymaking discretion of States. Nothing in this document preempts any State law or regulation. Therefore, this rule does not have sufficient federalism implications to warrant the preparation of a Federalism Impact Statement.</P>
                <HD SOURCE="HD2">H. Privacy</HD>
                <P>
                    The Consolidated Appropriations Act, 2005,
                    <SU>8</SU>
                    <FTREF/>
                     requires the Agency to assess the privacy impact of a regulation that will affect the privacy of individuals. This NPRM would not require the collection of personally identifiable information.
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         Public Law 108-447, 118 Stat. 2809, 3268, note following 5 U.S.C. 552a (Dec. 4, 2014).
                    </P>
                </FTNT>
                <PRTPAGE P="1058"/>
                <P>The Privacy Act (5 U.S.C. 552a) applies only to Federal agencies and any non-Federal agency that receives records contained in a system of records from a Federal agency for use in a matching program.</P>
                <P>
                    The E-Government Act of 2002,
                    <SU>9</SU>
                    <FTREF/>
                     requires Federal agencies to conduct a Privacy Impact Assessment (PIA) for new or substantially changed technology that collects, maintains, or disseminates information in an identifiable form. No new or substantially changed technology would collect, maintain, or disseminate information as a result of this rule. Accordingly, FMCSA has not conducted a PIA.
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         Public Law 107-347, sec. 208, 116 Stat. 2899, 2921 (Dec. 17, 2002).
                    </P>
                </FTNT>
                <P>In addition, the Agency submitted a Privacy Threshold Assessment (PTA) to evaluate the risks and effects the proposed rulemaking might have on collecting, storing, and sharing personally identifiable information. The DOT Privacy Office has determined that this rulemaking does not create privacy risk.</P>
                <HD SOURCE="HD2">I. E.O. 13175 (Indian Tribal Governments)</HD>
                <P>This rule does not have Tribal implications under E.O. 13175, Consultation and Coordination with Indian Tribal Governments, because it does not have a substantial direct effect on one or more Indian Tribes, on the relationship between the Federal Government and Indian Tribes, or on the distribution of power and responsibilities between the Federal Government and Indian Tribes.</P>
                <HD SOURCE="HD2">J. National Environmental Policy Act of 1969</HD>
                <P>
                    FMCSA analyzed this proposed rule pursuant to the National Environmental Policy Act of 1969 (42 U.S.C. 4321 
                    <E T="03">et seq.</E>
                    ) and determined this action is categorically excluded from further analysis and documentation in an environmental assessment or environmental impact statement under FMCSA Order 5610.1 (69 FR 9680), Appendix 2, paragraph 6.h. The categorical exclusion (CE) in paragraph 6.h. covers regulations and actions taken pursuant to regulation implementing procedures to collect fees that will be charged for motor carrier registrations. The proposed requirements in this rule are covered by this CE.
                </P>
                <HD SOURCE="HD2">K. Rulemaking Summary</HD>
                <P>
                    As required by 5 U.S.C. 553(b)(4), a summary of this rule can be found in the Abstract section of the Department's Unified Agenda entry for this rulemaking at 
                    <E T="03">https://www.reginfo.gov/public/do/eAgendaMain.</E>
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 49 CFR Part 367</HD>
                    <P>Intergovernmental relations, Motor carriers, Brokers, Freight Forwarders.</P>
                </LSTSUB>
                <P>Accordingly, FMCSA proposes to amend Title 49 CFR, subtitle B, chapter III, part 367 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 367—STANDARDS FOR REGISTRATION WITH STATES</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 367 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority: </HD>
                    <P>49 U.S.C. 13301, 14504a; and 49 CFR 1.87.</P>
                </AUTH>
                <AMDPAR>2. Remove and reserve § 367.20.</AMDPAR>
                <AMDPAR>3. Revise § 367.40 to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 367.40</SECTNO>
                    <SUBJECT>Fees under the Unified Carrier Registration Plan and Agreement for Registration Year 2024.</SUBJECT>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,r75,20,14">
                        <TTITLE>Table 1 to § 367.40—Fees Under the Unified Carrier Registration Plan and Agreement for Registration Year 2024</TTITLE>
                        <BOXHD>
                            <CHED H="1">Bracket</CHED>
                            <CHED H="1">
                                Number of commercial motor vehicles owned or
                                <LI>operated by exempt or non-exempt motor carrier, motor</LI>
                                <LI>private carrier, or freight forwarder</LI>
                            </CHED>
                            <CHED H="1">
                                Fee per entity for
                                <LI>exempt or non-exempt</LI>
                                <LI>motor carrier, motor</LI>
                                <LI>private carrier, or</LI>
                                <LI>freight forwarder</LI>
                            </CHED>
                            <CHED H="1">
                                Fee per entity
                                <LI>for broker or</LI>
                                <LI>leasing company</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">B1</ENT>
                            <ENT>0-2</ENT>
                            <ENT>$37</ENT>
                            <ENT>$37</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">B2</ENT>
                            <ENT>3-5</ENT>
                            <ENT>111</ENT>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">B3</ENT>
                            <ENT>6-20</ENT>
                            <ENT>221</ENT>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">B4</ENT>
                            <ENT>21-100</ENT>
                            <ENT>769</ENT>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">B5</ENT>
                            <ENT>101-1,000</ENT>
                            <ENT>3,670</ENT>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">B6</ENT>
                            <ENT>1,001 and above</ENT>
                            <ENT>35,836</ENT>
                            <ENT/>
                        </ROW>
                    </GPOTABLE>
                </SECTION>
                <AMDPAR>4. Add § 367.50 to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 367.50</SECTNO>
                    <SUBJECT>Fees under the Unified Carrier Registration Plan and Agreement for Registration Years Beginning in 2025 and Each Subsequent Registration Year Thereafter.</SUBJECT>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,r75,20,14">
                        <TTITLE>Table 1 to § 367.50—Fees Under the Unified Carrier Registration Plan and Agreement for Registration Years Beginning in 2025 and Each Subsequent Registration Year Thereafter</TTITLE>
                        <BOXHD>
                            <CHED H="1">Bracket</CHED>
                            <CHED H="1">
                                Number of commercial motor vehicles owned or
                                <LI>operated by exempt or non-exempt motor carrier, motor</LI>
                                <LI>private carrier, or freight forwarder</LI>
                            </CHED>
                            <CHED H="1">
                                Fee per entity for
                                <LI>exempt or non-exempt</LI>
                                <LI>motor carrier, motor</LI>
                                <LI>private carrier, or</LI>
                                <LI>freight forwarder</LI>
                            </CHED>
                            <CHED H="1">
                                Fee per entity
                                <LI>for broker or</LI>
                                <LI>leasing company</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">B1</ENT>
                            <ENT>0-2</ENT>
                            <ENT>$46</ENT>
                            <ENT>$46</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">B2</ENT>
                            <ENT>3-5</ENT>
                            <ENT>138</ENT>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">B3</ENT>
                            <ENT>6-20</ENT>
                            <ENT>276</ENT>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">B4</ENT>
                            <ENT>21-100</ENT>
                            <ENT>963</ENT>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">B5</ENT>
                            <ENT>101-1,000</ENT>
                            <ENT>4,592</ENT>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="1059"/>
                            <ENT I="01">B6</ENT>
                            <ENT>1,001 and above</ENT>
                            <ENT>44,836</ENT>
                            <ENT/>
                        </ROW>
                    </GPOTABLE>
                </SECTION>
                <SIG>
                    <P>Issued under authority delegated in 49 CFR 1.87.</P>
                    <NAME>Robin Hutcheson,</NAME>
                    <TITLE>Administrator.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00262 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-EX-P</BILCOD>
        </PRORULE>
    </PRORULES>
    <VOL>89</VOL>
    <NO>6</NO>
    <DATE>Tuesday, January 9, 2024</DATE>
    <UNITNAME>Notices</UNITNAME>
    <NOTICES>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="1060"/>
                <AGENCY TYPE="F">AGENCY FOR INTERNATIONAL DEVELOPMENT</AGENCY>
                <SUBJECT>Agency Information Collection Activities; Submission to the Office of Management and Budget for Review and Approval; Comment Request; Information Collection Generic Clearance Request for USAID Workforce and Organizational Surveys</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Bureau for Management, Office of the Director, (M/MPBP/OD), Agency for International Development (USAID).</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>USAID proposes a generic clearance to collect workforce feedback through surveys, interviews, and focus groups to optimize operations, strengthen organizational health and workforce culture, and improve workforce retention. USAID has a diverse workforce that consists of U.S. direct hires (foreign and civil service) and multiple contract mechanisms with the majority of the workforce belonging to multiple contract mechanisms, including Coordinating Country Nationals, Personal Services Contractors, and Institutional Support Contractors.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Interested persons are invited to submit comments within 30 days of this notice.</P>
                    <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 by selecting “Currently under 30-day Review—Open for Public Comments” or by using the search function.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may send comments by email to:</P>
                    <P>
                        • 
                        <E T="03">Email: oscholbe@usaid.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Owain Scholbe, Junior Management and Program Analyst, Management Bureau, Office of the Director (M/MPBP/OD), telephone 202-921-5070, or via email at 
                        <E T="03">oscholbe@usaid.gov.</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. 3506(c)(2)(A)), USAID is providing the general public and Federal agencies with an opportunity to comment on the proposed collection of information. USAID is requesting a general clearance to provide and conduct workforce surveys, interviews, and focus groups with a diverse workforce consisting of numerous hiring mechanisms, including, but not limited to, U.S. direct hires, fellows, interns, Personal Services Contractors, Institutional Support Contractors, Coordinating Country Nationals, and Third Country Nationals. The goal of data collection under this generic clearance is to collect workforce feedback on organizational health, operations, workforce culture, and work environment necessary to strengthen mission readiness and better achieve its development objectives. USAID will only collect data from the approximately 11,000 members of the USAID workforce with minimal collection of personally identifiable information. The total estimated number of annual burden hours for these workforce population surveys is 41,250 hours. USAID will limit analysis and reporting to summary level statistics that will only be available to the internal workforce.</P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     TBD.
                </P>
                <SIG>
                    <DATED>Dated: December 4, 2023.</DATED>
                    <NAME>Erin Brown,</NAME>
                    <TITLE>Deputy Director, M/MPBP.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00207 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6116-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF AGRICULTURE</AGENCY>
                <SUBJECT>Submission for OMB Review; Comment Request</SUBJECT>
                <P>The Department of Agriculture has submitted the following information collection requirement(s) to OMB for review and clearance under the Paperwork Reduction Act of 1995, Public Law 104-13. Comments are requested regarding; whether the collection of information is necessary for the proper performance of the functions of the agency, including whether the information will have practical utility; the accuracy of the agency's estimate of burden including the validity of the methodology and assumptions used; ways to enhance the quality, utility and clarity of the information to be collected; and ways to minimize the burden of the collection of information on those who are to respond, including through the use of appropriate automated, electronic, mechanical, or other technological collection techniques or other forms of information technology.</P>
                <P>
                    Comments regarding this information collection received by February 8, 2024 will be considered. Written comments and recommendations for the proposed information collection should be submitted within 30 days of the publication of this notice on the following website 
                    <E T="03">www.reginfo.gov/public/do/PRAMain.</E>
                     Find this particular information collection by selecting “Currently under 30-day Review—Open for Public Comments” or by using the search function.
                </P>
                <P>An agency may not conduct or sponsor a collection of information unless the collection of information displays a currently valid OMB control number, and the agency informs potential persons who are to respond to the collection of information that such persons are not required to respond to the collection of information unless it displays a currently valid OMB control number.</P>
                <HD SOURCE="HD1">Animal and Plant Health Inspection Service</HD>
                <P>
                    <E T="03">Title:</E>
                     Blood and Tissue Collection, and Recordkeeping, at Slaughtering, Rendering, and Approved Livestock Marketing Establishments and Facilities.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     0579-0212.
                </P>
                <P>
                    <E T="03">Summary of Collection:</E>
                     The Animal Health Protection Act (AHPA) of 2002 is the primary Federal law governing the protection of animal health. The AHPA is contained in title X, subtitle E, sections 10401-18 of Public Law 107-171, May 13, 2002, the Farm Security and Rural Investment Act of 2002. As part of its mission to monitor and test for livestock diseases, the Department of Agriculture, Animal and Plant Health Inspection Service (APHIS), Veterinary Services (VS), maintains with approved slaughtering, rendering, and livestock marketing establishments and facilities agreements and procedures for animal disease surveillance and reporting, 
                    <PRTPAGE P="1061"/>
                    maintaining livestock movement records, and collecting blood and tissue samples. These agreements and procedures include information collection activities such as Approved Livestock Facility Agreements, Requests for Appeal of Denial of Agreement, Withdrawal of Livestock Facility Agreements, Requests for Appeal of Withdrawal of Agreements, Listing Agreements for Slaughter or Rendering Establishments, Slaughter or Rendering Facility Inspection Reports, Requests for Appeal of Denial of Listings, Requests for Appeal of Withdrawal of Listing, Schedules of Sales Days, Diseased Animal Notifications, Quarantine Signs, and maintaining animal movement records.
                </P>
                <P>
                    <E T="03">Need and Use of the Information:</E>
                     The collection of this information identifies and prevents the interstate movement of unhealthy livestock animals with diseases within the United States. The information collected is used to: (1) establish Livestock Facility Agreements and Listing Agreements between APHIS and owners and operators of slaughtering and rendering establishments and livestock marketing facilities, (2) rapidly confirm livestock disease occurrences through reporting and sampling, (3) trace the sources of diseases, as well as the movement of other potentially infected animals, and (4) provide epidemiological data for new or updated risk analyses in support of disease control programs, and, as required, opening international markets for animal products. Without the agreements and sampling/reporting procedures, the risk of contagious disease spread becomes very high with serious consequences for U.S. meat industries and export markets.
                </P>
                <P>
                    <E T="03">Description of Respondents:</E>
                     Business or other-for profit; State, Local or Tribal Government.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     1,914.
                </P>
                <P>
                    <E T="03">Frequency of Responses:</E>
                     Reporting: On occasion.
                </P>
                <P>
                    <E T="03">Total Burden Hours:</E>
                     3,352.
                </P>
                <SIG>
                    <NAME>Levi S. Harrell,</NAME>
                    <TITLE>Departmental Information Collection Clearance Officer.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00226 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3410-34-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF AGRICULTURE</AGENCY>
                <SUBAGY>Animal and Plant Health Inspection Service</SUBAGY>
                <DEPDOC>[Docket No. APHIS-2023-0077]</DEPDOC>
                <SUBJECT>Reclassification of Nuevo León, Mexico to Level V for Bovine Tuberculosis</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Animal and Plant Health Inspection Service, USDA.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>We are advising the public that we have reclassified the region of Nuevo León, Mexico as Level V for bovine tuberculosis. Previously, the Nuevo León region was classified as Level IV for bovine tuberculosis. We took this action based on an onsite review of the bovine tuberculosis control and eradication program in Nuevo León.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The revised classification was effective December 1, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Dr. Kari Coulson, Import Risk Analyst, Regionalization Evaluation Services, Strategy and Policy, VS, APHIS, USDA, 920 Main Campus Drive, Raleigh, NC 27606; (919) 480-9876; 
                        <E T="03">AskRegionalization@usda.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The regulations in 9 CFR part 93, subpart D (§§ 93.400 through 93.442, referred to below as part 93 or the subpart), contain requirements for the importation of ruminants into the United States to address the risk of introducing or disseminating diseases of livestock within the United States. Part 93 currently contains provisions that address the risk that imported bovines (cattle or bison) may introduce or disseminate bovine tuberculosis within the United States. Within part 93, § 93.437 contains the requirements for classification of foreign regions for bovine tuberculosis and § 93.438 contains the process for requesting regional classification for bovine tuberculosis.</P>
                <P>In accordance with § 93.437(f), the Animal and Plant Health Inspection Service (APHIS) maintains lists of all Level I, Level II, Level III, Level IV, and Level V regions for bovine tuberculosis and makes changes to the lists in accordance with § 93.438. In accordance with § 93.437(e), regions that do not have a program that meets APHIS requirements for bovine tuberculosis classification, have a prevalence of bovine tuberculosis in their domestic bovine herds equal to or greater than 0.5 percent, or are unassessed by APHIS with regard to bovine tuberculosis are considered to be Level V.</P>
                <P>
                    Paragraph (d) of § 93.438 provides that a region may be required to allow APHIS to conduct additional information collection activities in order for that region to maintain its classification for bovine tuberculosis. If APHIS determines that a region's classification is no longer accurate, APHIS will publish a notice in the 
                    <E T="04">Federal Register</E>
                     announcing the revised classification and setting forth the reasons for the reclassification.
                </P>
                <P>In March 2023, APHIS conducted an onsite review of the bovine tuberculosis control and eradication program in Nuevo León. At the time of this review, APHIS recognized the Nuevo León region as Level IV status for bovine tuberculosis. The review determined that the region no longer has a program that meets APHIS minimum requirements for Level IV status due to deficiencies in the following areas: Veterinary control and oversight; epidemiological investigations; management of affected herds; regulatory controls on the movement of livestock; and surveillance. These findings support reclassifying Nuevo León as Level V for bovine tuberculosis.</P>
                <P>With the publication of this notice, we are announcing the revised classification of the Nuevo León region of Mexico to Level V for bovine tuberculosis, effective December 1, 2023. This notice serves as an official record and public notification of this action.</P>
                <P>
                    Pursuant to the Congressional Review Act (5 U.S.C. 801 
                    <E T="03">et seq.</E>
                    ), the Office of Information and Regulatory Affairs designated this action as not a major rule, as defined by 5 U.S.C. 804(2).
                </P>
                <P>
                    <E T="03">Authority:</E>
                     7 U.S.C. 1622 and 8301-8317; 21 U.S.C. 136 and 136a; 31 U.S.C. 9701; 7 CFR 2.22, 2.80, and 371.4.
                </P>
                <SIG>
                    <DATED>Done in Washington, DC, this 4th day of January 2024.</DATED>
                    <NAME>Donna Lalli,</NAME>
                    <TITLE>Acting Administrator, Animal and Plant Health Inspection Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00265 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3410-34-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="1062"/>
                <AGENCY TYPE="S">DEPARTMENT OF AGRICULTURE</AGENCY>
                <SUBAGY>Natural Resources Conservation Service</SUBAGY>
                <SUBJECT>Mississippi Trustee Implementation Group Deepwater Horizon Oil Spill Final Restoration Plan 4 and Environmental Assessment: Restoration of Wetlands, Coastal, and Nearshore Habitats; Nutrient Reduction (Nonpoint Source); and Provide and Enhance Recreational Opportunities; and Finding of No Significant Impact</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Natural Resources Conservation Service (NRCS), U.S. Department of Agriculture (USDA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of availability.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Oil Pollution Act of 1990 (OPA), the National Environmental Policy Act of 1969 (NEPA), the Deepwater Horizon (DWH) Oil Spill Final Programmatic Damage Assessment Restoration Plan and Final Programmatic Environmental Impact Statement and Record of Decision, and the Consent Decree referenced below, the Federal and State natural resource trustee agencies for the Mississippi Trustee Implementation Group (MS TIG) have prepared and are making available to the public the “Mississippi Trustee Implementation Group Final Restoration Plan 4 and Environmental Assessment: Restoration of Wetlands, Coastal, and Nearshore Habitats; Nutrient Reduction (Nonpoint Source), and Provide and Enhance Recreational Opportunities” (Final RP4 and EA); and Finding of No Significant Impact (FONSI). The Final RP4 and EA analyzes projects to partially restore wetlands, coastal, and nearshore habitats; reduce nutrient pollution (nonpoint source); and provide and enhance recreational opportunities to compensate for lost recreational use in the Mississippi Restoration Area resulting from the DWH oil spill. The Final RP4 and EA evaluates a reasonable range of project alternatives under OPA, the OPA Natural Resources Damage Assessment (NRDA) regulations, and NEPA and the NEPA implementing regulations, and selects seven projects for funding and implementation. A No Action alternative is also evaluated for each of the restoration types. The estimated cost to implement MS TIG's proposed action (seven preferred alternatives) is $26.4 million. Of this amount, $18,500,000 will be funded from the Wetlands, Coastal and Nearshore Habitats restoration allocation, $5,000,000 from the Nutrient Reduction restoration allocation, and $2,853,000 from the Recreational Use restoration allocation.</P>
                </SUM>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        <E T="03">Obtaining Documents:</E>
                         You may download the Final RP4 and EA and FONSI from the following website: 
                        <E T="03">https://gulfspillrestoration.noaa.gov/media/document/2024-01-ms-final-rp4ea</E>
                         in the “Restoration Plans” section. Alternatively, you may request a CD of the Final RP4 and EA (see 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                        ).
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Nanciann Regalado at 
                        <E T="03">nanciann_regalado@fws.gov or</E>
                         678-296-6805, or via the Federal Relay Service at 800-877-8339; Ronald Howard, Senior Advisor, USDA Gulf Coast Ecosystem Restoration Team, at 
                        <E T="03">ron.howard@usda.gov</E>
                        ; and Dr. Tina Nations, NRDA Program Manager, MDEQ Office of Restoration, at 
                        <E T="03">mississippiTIG@mdeq.ms.gov</E>
                        . Individuals who require alternative means for communication should contact the USDA TARGET Center at (202) 720-2600 (voice and text telephone (TTY)) or dial 711 for Telecommunications Relay Service (both voice and text telephone users can initiate this call from any telephone).
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Introduction</HD>
                <P>On April 20, 2010, the mobile offshore drilling unit Deepwater Horizon, which was being used to drill a well for BP Exploration and Production, Inc. (BP), in the Macondo prospect (Mississippi Canyon 252-MC252), experienced a significant explosion, fire, and subsequent sinking in the Gulf of Mexico, resulting in an unprecedented volume of oil and other discharges from the rig and from the wellhead on the seabed. The DWH oil spill is the largest offshore oil spill in U.S. history, discharging millions of barrels of oil over a period of 87 days. In addition, well over 1 million gallons of dispersants were applied to the waters of the spill area in an attempt to disperse the spilled oil. An undetermined amount of natural gas was also released into the environment as a result of the spill.</P>
                <P>The DWH Federal and State natural resource trustees (DWH Trustees) conducted NRDA for the DWH oil spill under OPA (33 U.S.C. 2701-2720). Pursuant to OPA, Federal, and State agencies act as trustees on behalf of the public, to assess natural resources injuries and losses and to determine the actions required to compensate the public for those injuries and losses. OPA further instructs the designated trustees to develop and implement a plan for the restoration, rehabilitation, replacement, or acquisition of the equivalent of the injured natural resources under their trusteeship to baseline (the resource quality and conditions that would exist if the spill had not occurred). This includes the loss of use and services provided by those resources from the time of injury until the completion of restoration.</P>
                <P>The DWH Trustees are:</P>
                <P>• U.S. Department of the Interior (DOI), as represented by the National Park Service, U.S. Fish and Wildlife Service, and Bureau of Land Management;</P>
                <P>• National Oceanic and Atmospheric Administration (NOAA), on behalf of the U.S. Department of Commerce;</P>
                <P>• USDA;</P>
                <P>• U.S. Environmental Protection Agency (EPA);</P>
                <P>• State of Louisiana Coastal Protection and Restoration Authority, Oil Spill Coordinator's Office, Department of Environmental Quality, Department of Wildlife and Fisheries, and Department of Natural Resources;</P>
                <P>• State of Mississippi Department of Environmental Quality;</P>
                <P>• State of Alabama Department of Conservation and Natural Resources and Geological Survey of Alabama;</P>
                <P>• State of Florida Department of Environmental Protection and Fish and Wildlife Conservation Commission; and</P>
                <P>• State of Texas: Texas Parks and Wildlife Department, Texas General Land Office, and Texas Commission on Environmental Quality.</P>
                <P>
                    On April 4, 2016, the United States District Court for the Eastern District of Louisiana entered a Consent Decree resolving civil claims by the DWH Trustees against BP arising from the DWH oil spill: 
                    <E T="03">United States</E>
                     v. 
                    <E T="03">BPXP et al.,</E>
                     Civ. No. 10-4536, centralized in MDL 2179, In re: Oil Spill by the Oil Rig “Deepwater Horizon” in the Gulf of Mexico, on April 20, 2010 (E.D. La.) (
                    <E T="03">https://www.justice.gov/enrd/deepwater-horizon</E>
                    ). Pursuant to the Consent Decree, restoration projects in the Mississippi Restoration Area are chosen and managed by MS TIG. MS TIG is composed of the following Trustees: State of Mississippi Department of Environmental Quality; DOI; NOAA; EPA; and USDA.
                </P>
                <P>On February 7, 2022, MS TIG posted public notice requesting natural resource restoration project ideas by March 7, 2022, for the Mississippi Restoration Area. The notice stated that MS TIG was seeking project ideas for the following restoration types:</P>
                <P>(1) Wetlands, Coastal, and Nearshore Habitat;</P>
                <P>(2) Nutrient Reduction; and</P>
                <P>
                    (3) Provide and Enhance Recreational Opportunities.
                    <PRTPAGE P="1063"/>
                </P>
                <P>
                    On October 11, 2022, the MS TIG announced that it had initiated drafting of the RP4 and EA (
                    <E T="03">https://www.gulfspillrestoration.noaa.gov/2022/10/notice-initiation-restoration-planning-mississippi</E>
                    ) and that the plan may include proposed projects for some or all of the three restoration types.
                </P>
                <HD SOURCE="HD1">Overview of the MS TIG Draft RP4 and EA</HD>
                <P>
                    MS TIG released the Draft RP4 and EA for public review and comment announced through a notice published in the 
                    <E T="04">Federal Register</E>
                     on August 31, 2023 (88 FR 60174-60176). The 30-day comment period for the notice closed on October 2, 2023. To facilitate public understanding of the document, MS TIG released a pre-recorded webinar on September 12, 2023, which had been announced in the August notice. In addition, the Draft RP and EA was made available to the public through a web story posted on MS TIG's website (
                    <E T="03">www.gulfspillrestoration.noaa.gov</E>
                    ). Informally, MS TIG accepted additional public comments through October 13, 2023, as announced on the MS TIG's website. MS TIG received three comments from the public. MS TIG reviewed the comments received, prepared responses to those comments, finalized the RP4 and EA, and prepared a FONSI.
                </P>
                <HD SOURCE="HD1">Overview of MS TIG Final RP4 and EA</HD>
                <P>In the Final RP4 and EA, MS TIG analyzes a reasonable range of 10 restoration alternatives and, pursuant to NEPA, a no action alternative for each of the restoration types. MS TIG selected seven preferred alternatives for funding and implementation, which are listed in the table below:</P>
                <GPOTABLE COLS="1" OPTS="L2,nj,tp0,p0,7/8,i1" CDEF="s100">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                    </BOXHD>
                    <ROW RUL="s">
                        <ENT I="22">Restoration Type: Wetlands, Coastal and Nearshore Habitat:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Coastwide Habitat Acquisition.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Living Shoreline Bulkhead Alternative.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="02">Hancock County Marsh Living Shoreline Phase 6 Breakwater.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="22">Restoration Type: Nutrient Reduction (Nonpoint Source):</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Back Bay—Davis Bayou Nutrient Reduction.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="02">Big Cedar Creek—Rocky Creek Nutrient Reduction.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="22">Restoration Type: Provide and Enhance Recreational Opportunities:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Jourdan River Boardwalk.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Shepard State Park Recreational Enhancements—1.</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">Administrative Record</HD>
                <P>
                    The documents comprising the Administrative Record for the Final RP4 and EA can be viewed electronically at 
                    <E T="03">https://www.doi.gov/deepwaterhorizon/adminrecord</E>
                     under the folder 6.5.6.2.4.
                </P>
                <HD SOURCE="HD1">Authorities</HD>
                <P>The authorities for this action are OPA, its implementing NRDA regulations in 15 CFR part 990; and NEPA (42 U.S.C. 4321—4347) and its implementing regulations in 40 CFR parts 1500-1508.</P>
                <SIG>
                    <NAME>Ronald Howard,</NAME>
                    <TITLE>Senior Technical Advisor, Natural Resource Specialist, Natural Resources Conservation Service, and U.S. Department of Agriculture, Alternate to Principal Representative.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00167 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3410-16-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>Foreign-Trade Zones Board</SUBAGY>
                <DEPDOC>[B-1-2024]</DEPDOC>
                <SUBJECT>Foreign-Trade Zone (FTZ) 297, Notification of Proposed Production Activity; Twin Disc, Inc.; (Power Transmission Products); Lufkin, Texas</SUBJECT>
                <P>Twin Disc, Inc. submitted a notification of proposed production activity to the FTZ Board (the Board) for its facility in Lufkin, Texas within Subzone 297A. The notification conforming to the requirements of the Board's regulations (15 CFR 400.22) was received on December 27, 2023.</P>
                <P>
                    Pursuant to 15 CFR 400.14(b), FTZ production activity would be limited to the specific foreign-status material(s)/component(s) and specific finished product(s) described in the submitted notification (summarized below) and subsequently authorized by the Board. The benefits that may stem from conducting production activity under FTZ procedures are explained in the background section of the Board's website—accessible via 
                    <E T="03">www.trade.gov/ftz.</E>
                </P>
                <P>The proposed finished products include power take-offs, pump drives, clutches, and hydrojet engines for marine propulsion (duty rate ranges from duty-free to 2.8%).</P>
                <P>The proposed foreign-status materials and components include: acrylic polymer seals; plastic plugs; rubber components (shaped blocks; nitrile O-rings and seals; air bladders); hydraulic hoses with fittings; paper tags; adhesive labels; owner manuals (printed; digital); clutch friction plates; alloy steel metal components (tubes; pipe fittings; pipe plugs; fasteners and fittings; nuts; washers; snap rings; rivets; cotter pins; freeze plugs; serrated lock washers); cast iron metal components (pipe fittings; tanks); metal components (screws; name plates; piston rings); various pins (Clevis; dowel; headed; roll; tapered); various springs (compression; torsion; wave); brass fittings and rivets; copper washers; Allen wrenches; hydrojet engine components (shafts; housings; caps; spacers; bushings; covers; anodes; retainers; fabricated tunnels); hydraulic pumps; pump parts; heat exchangers; hydraulic fluid filters; pressure reduction valves; valves; valve parts; various bearings (ball; tapered roller; spherical roller; needle; cylindrical roller); steel and roller balls; bearing cups and housings; transmission components (shafts; backplates; pressure plates; collars; yokes; brackets; drums; levers; links; sleeves; covers; drive rings; housings; adapters; keys; slingers; retainers; shims; spacers; locks); flywheels; shaft couplings; gears; marine propellers; flat panel displays; wiring harnesses; fluid level gauges; and, electronic sensors and control modules (duty rate ranges from duty-free to 9.9%). The request indicates that certain materials/components are subject to duties under section 232 of the Trade Expansion Act of 1962 (section 232) or section 301 of the Trade Act of 1974 (section 301), depending on the country of origin. The applicable section 232 and section 301 decisions require subject merchandise to be admitted to FTZs in privileged foreign status (19 CFR 146.41).</P>
                <P>
                    Public comment is invited from interested parties. Submissions shall be addressed to the Board's Executive Secretary and sent to: 
                    <E T="03">ftz@trade.gov.</E>
                     The closing period for their receipt is February 20, 2024.
                </P>
                <P>A copy of the notification will be available for public inspection in the “Online FTZ Information System” section of the Board's website.</P>
                <P>
                    For further information, contact Juanita Chen at 
                    <E T="03">juanita.chen@trade.gov.</E>
                </P>
                <SIG>
                    <DATED>Dated: January 3, 2024.</DATED>
                    <NAME>Elizabeth Whiteman,</NAME>
                    <TITLE>Executive Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00202 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DS-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="1064"/>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>Bureau of Industry and Security</SUBAGY>
                <DEPDOC>[Docket No. 231222-9999]</DEPDOC>
                <SUBJECT>Notice of Reestablishment of the President's Export Council Subcommittee on Export Administration and Solicitation of Nominations for Membership</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Bureau of Industry and Security, Department of Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>Pursuant to provisions of the Federal Advisory Committee Act, as amended, the Department of Commerce (the Department) announces the reestablishment of the President's Export Council Subcommittee on Export Administration (PECSEA) and solicits nominations for membership. The PECSEA will advise the Secretary of Commerce or the Secretary's designee on matters pertinent to the Export Control Reform Act of 2018 (ECRA), the International Emergency Economic Powers Act (IEEPA), and other relevant laws and regulations administered by the Bureau of Industry and Security (BIS), a component of the Department. The PECSEA will draw on the experiences and perspectives of its members to provide advice and make recommendations on protecting U.S. national security and foreign policy concerns through the administration of export controls while protecting U.S. technology leadership and commercial trade to ensure a strong U.S. defense industrial base.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Nominations for members must be received on or before 5 p.m. Eastern Standard Time (EST) on February 8, 2024. After that date, the Department may continue to accept nominations under this notice for up to approximately two years to fill any vacancies that may arise.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Nominations may be submitted via email to Ms. Yvette Springer, Committee Liaison Officer, Bureau of Industry and Security, U.S. Department of Commerce, at 
                        <E T="03">Yvette.Springer@bis.doc.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Ms. Yvette Springer via email or at 202-482-2813.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The PECSEA was originally established on June 1, 1976, as a subordinate committee of the President's Export Council (PEC), and the PECSEA charter was renewed biennially until the PECSEA terminated in 2019. The PECSEA is being reestablished under agency authority as a subordinate committee of the PEC and in accordance with section 1-205 of Executive Order (E.O.) 12131, “The President's Export Council” (May 4, 1979), as amended and as continued by successive E.O.s, most recently by E.O. 14109, “Continuance of Certain Federal Advisory Committees and Amendments to Other Executive Orders,” September 29, 2023, and in accordance with the provisions of the Federal Advisory Committee Act, as amended (FACA) (5 U.S.C. 1001 
                    <E T="03">et seq.</E>
                    ).
                </P>
                <P>The PECSEA is a discretionary committee and will function solely as an advisory body, complying with the provisions of FACA.</P>
                <P>
                    PECSEA members will be appointed by the Secretary of Commerce and serve at the Secretary's discretion. Members will generally serve two-year appointments and may be reappointed for membership by the Secretary. PECSEA members must be able to qualify for a Secret security clearance or a security clearance at a level sufficient to perform their work on PECSEA. The PECSEA will meet approximately three times per year. Members of PECSEA who are not otherwise paid a salary by the federal government shall receive no compensation from the U.S. by virtue of their service on the PECSEA, but may, upon their request, be allowed travel expenses, as authorized by 5 U.S.C. 5701 
                    <E T="03">et seq.</E>
                </P>
                <P>PECSEA will be composed of members selected from industry and other non-governmental organizations, drawn from among members of the PEC and other representatives of industry and other non-governmental organizations who are exporters of or otherwise engaged in activities related to items that are presently controlled under the Export Administration Regulations or are proposed for such control, balanced to the extent possible among large and small firms. The PECSEA is seeking private-sector members who are preferably senior executives with strategic authority within their companies and with significant operational control around production, supply chains, research and development activities, and/or international sales and should have an understanding of the impact of export controls on these functions and the broader marketplace.</P>
                <P>PECSEA will draw on the experiences and perspectives of its members to provide advice and make recommendations on protecting U.S. national security and foreign policy concerns through the administration of export controls while protecting U.S. technology leadership and commercial trade to ensure a strong U.S. defense industrial base. The diverse membership of the PECSEA assures perspectives reflecting the breadth of the PECSEA's responsibilities, and, where possible, the Department will also consider the ethnic, racial, and gender diversity and various abilities of the U.S. population.</P>
                <P>
                    <E T="03">To Apply:</E>
                     If you are interested in nominating someone or yourself to become a member of the PECSEA, please provide full name, title, employer name, and any other information you believe relevant to the nomination (2 pages maximum). Third-party nominations should state that the candidate agrees to the nomination.
                </P>
                <P>Please do not send organization brochures or any other information.</P>
                <P>
                    All applications should be submitted in pdf or MS Word format via email to the email address listed in 
                    <E T="02">ADDRESSES</E>
                     above by the deadline noted in 
                    <E T="02">DATES</E>
                     above.
                </P>
                <HD SOURCE="HD1">Privacy Act Statement</HD>
                <P>
                    The collection, maintenance, and disclosure of this information is governed by the Privacy Act of 1974 (5 U.S.C. 552a). The Department of Commerce is authorized to collect this information pursuant to authorities that include, but are not limited to, E.O. 12131, “The President's Export Council” (May 4, 1979), as amended and as continued by successive E.O.s, most recently by E.O. 14109, “Continuance of Certain Federal Advisory Committees and Amendments to Other Executive Orders,” September 29, 2023, and in accordance with the provisions of the FACA. The principal purpose for which the Department will use the information is to assist in choosing members for the PECSEA. Information received will be maintained in a Privacy Act system of records, COMMERCE/DEPT-11, entitled “Candidates for Membership, Members, and Former Members of Department of Commerce Advisory Committees.” A notice describing that system, including a complete set of routine disclosures, has been published both in the 
                    <E T="04">Federal Register</E>
                     and on the Department's website at: 
                    <E T="03">https://osec.doc.gov/opog/PrivacyAct/SORNs/dept-11.html.</E>
                     Although providing this information is voluntary, an individual cannot be considered for membership without an application submission, whether self-nominated or nominated by a third-party.
                </P>
                <SIG>
                    <PRTPAGE P="1065"/>
                    <DATED>Dated: January 3, 2024.</DATED>
                    <NAME>Alan F. Estevez,</NAME>
                    <TITLE>Under Secretary of Commerce for Industry and Security.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00190 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-JT-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <SUBJECT>Civil Nuclear Trade Advisory Committee: Meeting of the Civil Nuclear Trade Advisory Committee</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>International Trade Administration, U.S. Department of Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of Federal advisory committee meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice sets forth the schedule and proposed agenda for a meeting of the Civil Nuclear Trade Advisory Committee (CINTAC).</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The meeting is scheduled for Thursday, January 11, 2024, from 9 a.m. to 4 p.m. eastern standard time (EST). The deadline for members of the public to register, including requests to make comments during the meeting and for auxiliary aids, or to submit written comments for dissemination prior to the meeting, is 5 p.m. EST on Monday, January 8, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The meeting will be in-person at the Department of Commerce Herbert C. Hoover Building (1401 Constitution Ave. NW, Washington, DC 20230). Registered participants will be emailed instructions on accessing the designated meeting space. Requests to register (including to speak or for auxiliary aids) and any written comments should be submitted to Mr. Jonathan Chesebro, Office of Energy &amp; Environmental Industries, International Trade Administration, (email: 
                        <E T="03">jonathan.chesebro@trade.gov</E>
                        ). Members of the public should submit registration requests and written comments via email to ensure timely receipt.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Mr. Jonathan Chesebro, Office of Energy &amp; Environmental Industries, International Trade Administration, Room 28018, 1401 Constitution Ave. NW, Washington, DC 20230. (Phone: 202-482-1297; email: 
                        <E T="03">jonathan.chesebro@trade.gov.</E>
                        )
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Background:</E>
                     The CINTAC was established under the discretionary authority of the Secretary of Commerce and in accordance with the Federal Advisory Committee Act (5 U.S.C. 1001 
                    <E T="03">et seq.</E>
                    ), in response to an identified need for consensus advice from U.S. industry to the U.S. Government regarding the development and administration of programs to expand U.S. exports of civil nuclear goods and services in accordance with applicable U.S. laws and regulations, including advice on how U.S. civil nuclear goods and services export policies, programs, and activities affect the U.S. civil nuclear industry's competitiveness and ability to participate in the international market.
                </P>
                <P>
                    <E T="03">Topics to be considered:</E>
                     The agenda for the Thursday, January 11, 2024, CINTAC meeting will include discussions of CINTAC priorities for its 2022-2024 charter term and activities related to the U.S. Department of Commerce's Civil Nuclear Trade Initiative.
                </P>
                <P>Members of the public wishing to attend the meeting must notify Mr. Jonathan Chesebro at the contact information above by 5 p.m. EST on Monday, January 8, 2024, in order to pre-register. Please specify any requests for reasonable accommodation at least five business days in advance of the meeting.</P>
                <P>A limited amount of time will be available for brief oral comments from members of the public attending the meeting. To accommodate as many speakers as possible, the time for public comments will be limited to two (2) minutes per person, with a total public comment period of 20 minutes. Individuals wishing to reserve speaking time during the meeting must contact Mr. Jonathan Chesebro and submit a brief statement of the general nature of the comments and the name and address of the proposed participant by 5 p.m. EST on Monday, January 8, 2024. If the number of registrants requesting to make statements is greater than can be reasonably accommodated during the meeting, ITA may conduct a lottery to determine the speakers.</P>
                <P>Any member of the public may submit written comments concerning the CINTAC's affairs at any time before and after the meeting. Comments may be submitted to Mr. Jonathan Chesebro in the International Trade Administration's Office of Energy &amp; Environmental Industries. For consideration during the meeting, and to ensure transmission to the Committee prior to the meeting, comments must be received no later than 5:00 p.m. EST on Monday, January 8, 2024. Comments received after that date will be distributed to the members but may not be considered at the meeting.</P>
                <P>Copies of CINTAC meeting minutes will be available within 90 days of the meeting.</P>
                <SIG>
                    <DATED>Dated: January 3, 2024.</DATED>
                    <NAME>Man K. Cho,</NAME>
                    <TITLE>Deputy Director, Office of Energy and Environmental Industries. </TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00196 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <SUBJECT>Renewable Energy and Energy Efficiency Advisory Committee; Meeting</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>International Trade Administration, U.S. Department of Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of an open meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Renewable Energy and Energy Efficiency Advisory Committee (REEEAC or the Committee) will hold an in-person meeting, accessible to the public in-person and online, on Thursday, January 25, 2024 at the U.S. Department of Commerce in Washington, DC. Registration instructions for the public to attend either in-person or online are provided below. The meeting has a limited number of spaces for members of the public to attend in-person. Requests to attend in-person will be considered on a first-come first-served basis.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Thursday, January 25, 2024, from approximately 10 a.m. to 3:30 p.m. eastern daylight time (EDT). Members of the public wishing to participate must register in advance with Cora Dickson at the contact information below by 5 p.m. EDT on Monday, January 22, 2024, including any requests to make comments during the meeting or for accommodations or auxiliary aids.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        To register, please contact Cora Dickson, Designated Federal Officer (DFO), Office of Energy and Environmental Industries (OEEI), Industry and Analysis, International Trade Administration, U.S. Department of Commerce at (202) 482-6083; email: 
                        <E T="03">Cora.Dickson@trade.gov.</E>
                         In their registration, members of the public wishing to attend in-person must request in-person attendance by the firm deadline above.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Cora Dickson, DFO, Office of Energy and Environmental Industries (OEEI), Industry and Analysis, International Trade Administration, U.S. Department of Commerce at (202) 482-6083; email: 
                        <E T="03">Cora.Dickson@trade.gov.</E>
                         Registered participants joining virtually will be emailed the login information for the meeting, which will be accessible as a livestream via WebEx Webinar. 
                        <PRTPAGE P="1066"/>
                        Registered participants joining in-person will be emailed instructions on accessing the designated meeting space.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Background:</E>
                     The Secretary of Commerce established the REEEAC pursuant to discretionary authority and in accordance with the Federal Advisory Committee Act, as amended (5 U.S.C. 1001 
                    <E T="03">et seq.</E>
                    ), on July 14, 2010. The REEEAC was re-chartered most recently on May 27, 2022. The REEEAC provides the Secretary of Commerce with advice from the private sector on the development and administration of programs and policies to expand the export competitiveness of U.S. renewable energy and energy efficiency products and services. More information about the REEEAC, including the list of appointed members for this charter, is published online at 
                    <E T="03">http://trade.gov/reeeac.</E>
                </P>
                <P>On January 25, 2024, the REEEAC will hold the sixth meeting of its current charter term. The Committee will deliberate on approval of several recommendations. The REEEAC will also be briefed on recent ITA accomplishments of relevance to the U.S. renewable energy and energy efficiency industries, including the delegation to COP28, the launch of the Clean Tech Top Export Markets website, and the establishment of the Supply Chain Center. The agenda will be made available by January 22, 2024 upon request to Cora Dickson, and the most current version of the agenda will also be made available on the REEEAC website.</P>
                <P>
                    The meeting will be open to the public and will be accessible to people with disabilities. All guests are required to register in advance by the deadline identified under the 
                    <E T="02">DATES</E>
                     caption. Requests for auxiliary aids must be submitted by the registration deadline. Last minute requests will be accepted but may not be possible to fill.
                </P>
                <P>A limited amount of time before the close of the meeting will be available for oral comments from members of the public attending the meeting. Members of the public attending virtually who wish to speak during the public comment period must give the DFO advance notice in order to facilitate their access. To accommodate as many speakers as possible, the time for public comments will be limited to two to five minutes per person (depending on number of public participants). Individuals wishing to reserve speaking time during the meeting must contact Cora Dickson using the contact information above and submit a brief statement of the general nature of the comments, as well as the name and address of the proposed participant, by 5 p.m. EDT on Monday, January 22, 2024. If the number of registrants requesting to make statements is greater than can be reasonably accommodated during the meeting, the International Trade Administration may conduct a lottery to determine the speakers. Speakers are requested to submit a copy of their oral comments by email to Cora Dickson for distribution to the participants in advance of the meeting.</P>
                <P>
                    Any member of the public may submit written comments concerning the REEEAC's affairs at any time before or after the meeting. Comments may be submitted via email to the Renewable Energy and Energy Efficiency Advisory Committee, c/o: Cora Dickson, Designated Federal Officer, Office of Energy and Environmental Industries, U.S. Department of Commerce; 
                    <E T="03">Cora.Dickson@trade.gov.</E>
                     To be considered during the meeting, public comments must be transmitted to the REEEAC prior to the meeting. As such, written comments must be received no later than 5 p.m. EDT on Monday, January 22, 2024. Comments received after that date will be distributed to the members but may not be considered at the meeting.
                </P>
                <P>Copies of REEEAC meeting minutes will be available within 30 days following the meeting.</P>
                <SIG>
                    <DATED>Dated: January 3, 2024.</DATED>
                    <NAME>Man K. Cho,</NAME>
                    <TITLE>Deputy Director, Office of Energy and Environmental Industries.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00194 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <DEPDOC>[RTID 0648-XD284]</DEPDOC>
                <SUBJECT>Takes of Marine Mammals Incidental to Specified Activities; Taking Marine Mammals Incidental to the Hydaburg Seaplane Base Refurbishment Project in Hydaburg, Alaska</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>Issuance of an incidental harassment authorization.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the regulations implementing the Marine Mammal Protection Act (MMPA) as amended, notification is hereby given that NMFS has issued an incidental harassment authorization (IHA) to the Alaska Department of Transportation and Public Facilities (DOT&amp;PF) to incidentally harass marine mammals during construction associated with the Hydaburg Seaplane Base Refurbishment Project in Hydaburg, Alaska.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This authorization is effective from September 15, 2024 through September 14, 2025.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Electronic copies of the application and supporting documents, as well as a list of the references cited in this document, may be obtained online at: 
                        <E T="03">https://www.fisheries.noaa.gov/national/marine-mammal-protection/incidental-take-authorizations-construction-activities.</E>
                         In case of problems accessing these documents, please call the contact listed below.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Reny Tyson Moore, Office of Protected Resources, NMFS, (301) 427-8401.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    The MMPA prohibits the “take” of marine mammals, with certain exceptions. Sections 101(a)(5)(A) and (D) of the MMPA (16 U.S.C. 1361 
                    <E T="03">et seq.</E>
                    ) direct the Secretary of Commerce (as delegated to NMFS) to allow, upon request, the incidental, but not intentional, taking of small numbers of marine mammals by U.S. citizens who engage in a specified activity (other than commercial fishing) within a specified geographical region if certain findings are made and either regulations are proposed or, if the taking is limited to harassment, a notice of a proposed IHA is provided to the public for review.
                </P>
                <P>
                    Authorization for incidental takings shall be granted if NMFS finds that the taking will have a negligible impact on the species or stock(s) and will not have an unmitigable adverse impact on the availability of the species or stock(s) for taking for subsistence uses (where relevant). Further, NMFS must prescribe the permissible methods of taking and other “means of effecting the least practicable adverse impact” on the affected species or stocks and their habitat, paying particular attention to rookeries, mating grounds, and areas of similar significance, and on the availability of the species or stocks for taking for certain subsistence uses (referred to in shorthand as “mitigation”); and requirements pertaining to the mitigation, monitoring and reporting of the takings are set forth. The definitions of all applicable MMPA statutory terms cited above are included in the relevant sections below.
                    <PRTPAGE P="1067"/>
                </P>
                <HD SOURCE="HD1">Summary of Request</HD>
                <P>On June 28, 2022, NMFS received a request from DOT&amp;PF for an IHA to take marine mammals incidental to the Hydaburg Seaplane Base Refurbishment Project in Hydaburg, Alaska. Following NMFS' review of the application, and multiple discussions between DOT&amp;PF and NMFS, DOT&amp;PF submitted responses to NMFS questions on December 15, 2022 and a revised application on February 22, 2023. The application was deemed adequate and complete on March 13, 2023. DOT&amp;PF's request is for take of nine species of marine mammals by Level B harassment and, for a subset of 6 of these species, Level A harassment. Neither DOT&amp;PF nor NMFS expect serious injury or mortality to result from this activity and, therefore, an IHA is appropriate.</P>
                <HD SOURCE="HD1">Description of Activity</HD>
                <HD SOURCE="HD2">Overview</HD>
                <P>DOT&amp;PF, in cooperation with the Federal Aviation Administration, is planning maintenance improvements to the existing Hydaburg Seaplane Base as part of the Hydaburg Seaplane Base Refurbishment Project. The existing facility has experienced deterioration in recent years, and DOT&amp;PF has conducted several repair projects. The facility is near the end of its useful life, and replacement of the existing float structures is required to continue safe operation in the future. The in-water portion of the project will include the removal of five existing steel piles and installation of eight permanent steel piles to support replacement of the floating dock structure (Table 1). Up to 10 temporary steel piles will be installed to support permanent pile installation and will be removed following completion of permanent pile installation (Table 1). Activities included as part of the project with potential to affect marine mammals include vibratory removal, down-the-hole (DTH) installation, and vibratory and impact installation of steel pipe piles. Pile installation and removal will occur intermittently over 26 nonconsecutive days within a 2-month construction window, and is anticipated to begin in fall 2024.</P>
                <GPOTABLE COLS="11" OPTS="L2,p7,7/8,i1" CDEF="s50,8,8,8,8,9,12,12,11,11,11">
                    <TTITLE>Table 1—Summary of Piles To Be Installed and Removed</TTITLE>
                    <BOXHD>
                        <CHED H="1">
                            Pile diameter
                            <LI>and type</LI>
                        </CHED>
                        <CHED H="1">
                            Number
                            <LI>of piles</LI>
                        </CHED>
                        <CHED H="1">
                            Number
                            <LI>of rock</LI>
                            <LI>sockets</LI>
                        </CHED>
                        <CHED H="1">
                            Number
                            <LI>of</LI>
                            <LI>tension</LI>
                            <LI>anchors</LI>
                        </CHED>
                        <CHED H="1">
                            Impact
                            <LI>strikes</LI>
                            <LI>per pile</LI>
                        </CHED>
                        <CHED H="1">
                            Vibratory
                            <LI>duration</LI>
                            <LI>per pile</LI>
                            <LI>(minutes)</LI>
                        </CHED>
                        <CHED H="1">
                            Rock socket
                            <LI>DTH pile</LI>
                            <LI>installation,</LI>
                            <LI>duration per</LI>
                            <LI>pile, minutes</LI>
                            <LI>(range)</LI>
                        </CHED>
                        <CHED H="1">
                            Tension
                            <LI>anchor</LI>
                            <LI>DTH pile</LI>
                            <LI>installation,</LI>
                            <LI>duration per</LI>
                            <LI>pile, minutes</LI>
                            <LI>(range)</LI>
                        </CHED>
                        <CHED H="1">
                            Total
                            <LI>duration of</LI>
                            <LI>activity per</LI>
                            <LI>pile, hours</LI>
                        </CHED>
                        <CHED H="1">
                            Typical
                            <LI>production</LI>
                            <LI>rate in</LI>
                            <LI>piles per</LI>
                            <LI>day</LI>
                            <LI>(range)</LI>
                        </CHED>
                        <CHED H="1">
                            Days of
                            <LI>installation</LI>
                            <LI>or removal</LI>
                        </CHED>
                    </BOXHD>
                    <ROW EXPSTB="10" RUL="s">
                        <ENT I="21">
                            <E T="02">Pile Installation</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">24″ Steel Plumb Piles (Permanent)</ENT>
                        <ENT>4</ENT>
                        <ENT>4</ENT>
                        <ENT>4</ENT>
                        <ENT>50</ENT>
                        <ENT>15</ENT>
                        <ENT>240 (60-480)</ENT>
                        <ENT>120 (60-240)</ENT>
                        <ENT>6.75</ENT>
                        <ENT>0.5 (0-1)</ENT>
                        <ENT>8</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">20″ Steel Plumb Piles (Permanent)</ENT>
                        <ENT>4</ENT>
                        <ENT>2</ENT>
                        <ENT>2</ENT>
                        <ENT>50</ENT>
                        <ENT>15</ENT>
                        <ENT>240 (60-480)</ENT>
                        <ENT>120 (60-240)</ENT>
                        <ENT>
                            <SU>1</SU>
                             0.75/6.75
                        </ENT>
                        <ENT>0.5 (0-1)</ENT>
                        <ENT>8</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">24″ Steel Piles (Temporary)</ENT>
                        <ENT>10</ENT>
                        <ENT>5</ENT>
                        <ENT>N/A</ENT>
                        <ENT>N/A</ENT>
                        <ENT>15</ENT>
                        <ENT>240 (60-480)</ENT>
                        <ENT>N/A</ENT>
                        <ENT>4.25</ENT>
                        <ENT>2.5 (1-10)</ENT>
                        <ENT>4</ENT>
                    </ROW>
                    <ROW EXPSTB="10" RUL="s">
                        <ENT I="21">
                            <E T="02">Pile Removal</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">16″ Steel Cantilevered Piles</ENT>
                        <ENT>5</ENT>
                        <ENT>N/A</ENT>
                        <ENT>N/A</ENT>
                        <ENT>N/A</ENT>
                        <ENT>30</ENT>
                        <ENT>N/A</ENT>
                        <ENT>N/A</ENT>
                        <ENT>0.5</ENT>
                        <ENT>2.5 (2-4)</ENT>
                        <ENT>2</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="01">24″ Steel Piles (Temporary)</ENT>
                        <ENT>10</ENT>
                        <ENT>N/A</ENT>
                        <ENT>N/A</ENT>
                        <ENT>N/A</ENT>
                        <ENT>30</ENT>
                        <ENT>N/A</ENT>
                        <ENT>N/A</ENT>
                        <ENT>0.5</ENT>
                        <ENT>2.5 (2-4)</ENT>
                        <ENT>4</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Totals</ENT>
                        <ENT>23</ENT>
                        <ENT>11</ENT>
                        <ENT>6</ENT>
                        <ENT>N/A</ENT>
                        <ENT>N/A</ENT>
                        <ENT>N/A</ENT>
                        <ENT>N/A</ENT>
                        <ENT>N/A</ENT>
                        <ENT>N/A</ENT>
                        <ENT>26</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         Two of the 20-inch plumb piles will include vibratory and impact installation in addition to rock sockets and tension anchors, estimated at 6.75 hours duration total, and two will only use vibratory and impact, estimated at 0.75 hours duration total.
                    </TNOTE>
                </GPOTABLE>
                  
                <P>
                    A detailed description of the planned construction project is provided in the 
                    <E T="04">Federal Register</E>
                     notice for the proposed IHA (88 FR 45774, June 17, 2023). Since that time, no changes have been made to the planned activities. Therefore, a detailed description is not provided here. Please refer to that 
                    <E T="04">Federal Register</E>
                     notice for the description of the specific activity.
                </P>
                <P>Mitigation, monitoring, and reporting measures are described in detail later in this document (please see Mitigation and Monitoring and Reporting).</P>
                <HD SOURCE="HD1">Comments and Responses</HD>
                <P>
                    A notice of NMFS' proposal to issue an IHA to the DOT&amp;PF was published in the 
                    <E T="04">Federal Register</E>
                     on July 17, 2023 (88 FR 45774). That notice described, in detail, the DOT&amp;PF's activities, the marine mammal species that may be affected by the activities, and the anticipated effects on marine mammals. In that notice, we requested public input on the request for authorization described therein, our analyses, the proposed authorization, and any other aspect of the notice of proposed IHA, and requested that interested persons submit relevant information, suggestions, and comments. This proposed notice was available for a 30-day public comment period.
                </P>
                <P>
                    In the 
                    <E T="04">Federal Register</E>
                     notice of the proposed IHA, NMFS presented our assessment of DTH systems, which differed from DOT&amp;PF's assessment. Specifically, the DOT&amp;PF and NMFS disagreed about some of the source levels and transmission loss (TL) coefficients that should be used as proxies to estimate the ensonified area resulting from certain DTH activities. NMFS also disagreed with the DOT&amp;PF's assessment that sounds resulting from the DTH installation of 8 inch anchor piles should only be considered as continuous sound sources when calculating Level A and Level B harassment rather than as having both impulsive and continuous components as recommended by NMFS (2022) (
                    <E T="03">https://media.fisheries.noaa.gov/2022-11/PUBLIC%20DTH%20Basic%20Guidance_November%202022.pdf</E>
                    ). Available data does not support DOT&amp;PF's evaluation. NMFS' recommendations regarding analysis of sound produced through use of DTH techniques is based on the best available science and interpretation of available data by subject matter experts, and is publicly available online. NMFS explained these issues in the notice of the proposed IHA, and specifically 
                    <PRTPAGE P="1068"/>
                    requested public comment on its DTH-related recommendations in context of DOT&amp;PF's alternative interpretation.
                </P>
                <P>
                    During the 30-day public comment period, NMFS received comments from the Marine Mammal Commission (MMC). The MMC expressed support for NMFS' assessment and evaluation of DTH systems. Specifically, the MMC agrees with NMFS that DTH installation of all sized piles, including 8-inch tension anchors, should be considered an impulsive, continuous source and that NMFS should the use proxy source levels recommended by NMFS (2022) instead of those proposed by the DOT&amp;PF to estimate associated ensonified areas. In addition, the MMC agrees with NMFS' determination that applying proxy TL coefficients measured in other locations in Hydaburg is inappropriate, because transmission loss is dependent on sediment characteristics, bathymetry/water depth, and sound speed profiles in a given area. The MMC supports NMFS' decision to require the DOT&amp;PF to use practical spreading loss models (
                    <E T="03">i.e.,</E>
                     15 log R) when calculating ensonified areas resulting from DTH pile installation at Hydaburg, and recommends that NMFS continue to require action proponents to use practical spreading unless site-specific transmission loss data are available from the proposed project site. The comments and recommendations are available online at: 
                    <E T="03">https://www.fisheries.noaa.gov/national/marine-mammal-protection/incidental-take-authorizations-construction-activities.</E>
                     Please see the comment submission for full details regarding the recommendations and supporting rationale.
                </P>
                <HD SOURCE="HD1">Changes From the Proposed IHA to Final IHA</HD>
                <P>
                    Since the 
                    <E T="04">Federal Register</E>
                     notice of the proposed IHA was published (88 FR 45774, July 17, 2023), NMFS published the 2022 Alaska and Pacific Stock Assessment Reports (SARs), which provide updates to the humpback whale stock structure and Southeast Alaska harbor porpoise stock structure (Carretta 
                    <E T="03">et al.,</E>
                     2023; 
                    <E T="03">Young et al,</E>
                     2023). Updates have been made to the species descriptions for these species (see Description of Marine Mammals in the Area of Specified Activities) as well as to our analysis of take (see Estimated Take) and small numbers determinations (see Small Numbers).
                </P>
                <P>In addition, based on the comment letter received from the MMC in support of NMFS' assessment of DTH systems, the Estimated Take section in this notice only considers source levels and transmission loss coefficients recommended by NMFS (2022) for DTH systems as proxies to estimate associated ensonified areas (in contrast to including a discussion regarding the DOT&amp;PF's assessment of DTH systems). Specifically, DTH installation of all sized piles are considered to be an impulsive, continuous source; proxy source levels follow NMFS's recommendations for DTH systems (NMFS, 2022); and transmission loss of sounds produced by DTH systems in the Hydaburg project area are modelled assuming practical spreading loss.</P>
                <P>
                    Lastly, a typographical error identified in Table 1 in the 
                    <E T="04">Federal Register</E>
                     notice of the proposed IHA has been corrected in this 
                    <E T="04">Federal Register</E>
                     notice. Specifically, the number of estimated days of installation and removal of 24-inch steel piles included in the Table was incorrect. No other changes have been made from the proposed IHA to the final IHA.
                </P>
                <HD SOURCE="HD1">Description of Marine Mammals in the Area of Specified Activities</HD>
                <P>
                    Sections 3 and 4 of the DOT&amp;PF's application summarize available information regarding status and trends, distribution and habitat preferences, and behavior and life history of the potentially affected species. NMFS fully considered all of this information, and we refer the reader to these descriptions, referenced here, instead of reprinting the information. Additional information regarding population trends and threats may be found in NMFS' Stock Assessment Reports (SARs; 
                    <E T="03">www.fisheries.noaa.gov/national/marine-mammal-protection/marine-mammal-stock-assessments</E>
                    ) and more general information about these species (
                    <E T="03">e.g.,</E>
                     physical and behavioral descriptions) may be found on NMFS' website (
                    <E T="03">https://www.fisheries.noaa.gov/find-species</E>
                    ).
                </P>
                <P>Table 2 lists all species or stocks for which take is expected and authorized for this activity, and summarizes information related to the population or stock, including regulatory status under the MMPA and Endangered Species Act (ESA) and potential biological removal (PBR), where known. PBR is defined by the MMPA as the maximum number of animals, not including natural mortalities, that may be removed from a marine mammal stock while allowing that stock to reach or maintain its optimum sustainable population (as described in NMFS' SARs). While no serious injury or mortality is expected to occur, PBR and annual serious injury and mortality from anthropogenic sources are included here as gross indicators of the status of the species or stocks and other threats.</P>
                <P>
                    Marine mammal abundance estimates presented in this document represent the total number of individuals that make up a given stock or the total number estimated within a particular study or survey area. NMFS' stock abundance estimates for most species represent the total estimate of individuals within the geographic area, if known, that comprises that stock. For some species, this geographic area may extend beyond U.S. waters. All stocks managed under the MMPA in this region are assessed in NMFS' U.S. Alaska and Pacific SARs (
                    <E T="03">e.g.,</E>
                     Carretta, 
                    <E T="03">et al.,</E>
                     2023; Young 
                    <E T="03">et al.,</E>
                     2023). All values presented in Table 2 are the most recent available at the time of publication and are available online at: 
                    <E T="03">www.fisheries.noaa.gov/national/marine-mammal-protection/marine-mammal-stock-assessments</E>
                    .
                </P>
                <GPOTABLE COLS="7" OPTS="L2,p7,7/8,i1" CDEF="s50,r50,r50,xls30,r40,8,8">
                    <TTITLE>
                        Table 2—Species 
                        <SU>4</SU>
                         Likely Impacted by the Specified Activities
                    </TTITLE>
                    <BOXHD>
                        <CHED H="1">Common name</CHED>
                        <CHED H="1">Scientific name</CHED>
                        <CHED H="1">Stock</CHED>
                        <CHED H="1">
                            ESA/MMPA status;
                            <LI>strategic</LI>
                            <LI>
                                (Y/N) 
                                <SU>1</SU>
                            </LI>
                        </CHED>
                        <CHED H="1">
                            Stock 
                            <LI>abundance </LI>
                            <LI>
                                (CV, N
                                <E T="0732">min</E>
                                , most recent
                            </LI>
                            <LI>
                                abundance survey) 
                                <SU>2</SU>
                            </LI>
                        </CHED>
                        <CHED H="1">PBR</CHED>
                        <CHED H="1">
                            Annual
                            <LI>
                                M/SI 
                                <SU>3</SU>
                            </LI>
                        </CHED>
                    </BOXHD>
                    <ROW EXPSTB="06" RUL="s">
                        <ENT I="21">
                            <E T="02">Order Artiodactyla—Cetacea—Mysticeti (baleen whales)</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="22">
                            <E T="03">Family Balaenopteridae (rorquals):</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Humpback Whale</ENT>
                        <ENT>
                            <E T="03">Megaptera novaeangliae</E>
                        </ENT>
                        <ENT>Hawaii</ENT>
                        <ENT>-, -, N</ENT>
                        <ENT>11,278 (0.56, 7,265, 2020)</ENT>
                        <ENT>127</ENT>
                        <ENT>27.09</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>Mexico-North Pacific</ENT>
                        <ENT>T, D, Y</ENT>
                        <ENT>918 (0.217, UNK, 2006)</ENT>
                        <ENT>UND</ENT>
                        <ENT>0.57</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="03">Minke Whale</ENT>
                        <ENT>
                            <E T="03">Balaenoptera acutorostrata</E>
                        </ENT>
                        <ENT>Alaska</ENT>
                        <ENT>-, -, N</ENT>
                        <ENT>N/A (N/A, N/A, N/A)</ENT>
                        <ENT>UND</ENT>
                        <ENT>0</ENT>
                    </ROW>
                    <ROW EXPSTB="06" RUL="s">
                        <PRTPAGE P="1069"/>
                        <ENT I="21">
                            <E T="02">Odontoceti (toothed whales, dolphins, and porpoises)</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="22">
                            <E T="03">Family Delphinidae:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Killer Whale</ENT>
                        <ENT>
                            <E T="03">Orcinus orca</E>
                        </ENT>
                        <ENT>Eastern North Pacific Alaska Resident</ENT>
                        <ENT>-, -, N</ENT>
                        <ENT>1,920 (N/A, 1,920, 2019)</ENT>
                        <ENT>19</ENT>
                        <ENT>1.3</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Killer Whale</ENT>
                        <ENT>
                            <E T="03">Orcinus orca</E>
                        </ENT>
                        <ENT>Eastern Northern Pacific Northern Resident</ENT>
                        <ENT>-, -, N</ENT>
                        <ENT>302 (N/A, 302, 2018)</ENT>
                        <ENT>2.2</ENT>
                        <ENT>0.2</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Killer Whale</ENT>
                        <ENT>
                            <E T="03">Orcinus orca</E>
                        </ENT>
                        <ENT>West Coast Transient</ENT>
                        <ENT>-, -, N</ENT>
                        <ENT>349 (N/A, 349, 2018)</ENT>
                        <ENT>3.5</ENT>
                        <ENT>0.4</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Pacific White-Sided Dolphin</ENT>
                        <ENT>
                            <E T="03">Lagenorhynchus obliquidens</E>
                        </ENT>
                        <ENT>N Pacific</ENT>
                        <ENT>-, -, N</ENT>
                        <ENT>26,880 (N/A, N/A, 1990)</ENT>
                        <ENT>UND</ENT>
                        <ENT>0</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">
                            <E T="03">Family Phocoenidae (porpoises):</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Dall's Porpoise</ENT>
                        <ENT>
                            <E T="03">Phocoenoides dalli</E>
                        </ENT>
                        <ENT>Alaska</ENT>
                        <ENT>-, -, N</ENT>
                        <ENT>UND (UND, UND, 2015)</ENT>
                        <ENT>UND</ENT>
                        <ENT>37</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Harbor Porpoise</ENT>
                        <ENT>
                            <E T="03">Phocoena phocoena</E>
                        </ENT>
                        <ENT>Southern Southeast Alaska Inland Waters</ENT>
                        <ENT>-, -, Y</ENT>
                        <ENT>890 (0.37, 610, 2019)</ENT>
                        <ENT>6.1</ENT>
                        <ENT>7.4</ENT>
                    </ROW>
                    <ROW EXPSTB="06" RUL="s">
                        <ENT I="21">
                            <E T="02">Order Carnivora—Pinnipedia</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="22">
                            <E T="03">Family Otariidae (eared seals and sea lions):</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Steller Sea Lion</ENT>
                        <ENT>
                            <E T="03">Eumetopias jubatus</E>
                        </ENT>
                        <ENT>Eastern</ENT>
                        <ENT>-, -, N</ENT>
                        <ENT>43,201 (N/A, 43,201, 2017)</ENT>
                        <ENT>2,592</ENT>
                        <ENT>112</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">
                            <E T="03">Family Phocidae (earless seals):</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Harbor Seal</ENT>
                        <ENT>
                            <E T="03">Phoca vitulina</E>
                        </ENT>
                        <ENT>Dixon/Cape Decision</ENT>
                        <ENT>-, -, N</ENT>
                        <ENT>23,478 (N/A, 21,453, 2015)</ENT>
                        <ENT>644</ENT>
                        <ENT>69</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Northern Elephant Seal</ENT>
                        <ENT>
                            <E T="03">Mirounga angustirostris</E>
                        </ENT>
                        <ENT>CA Breeding</ENT>
                        <ENT>-, -, N</ENT>
                        <ENT>187,386 (N/A, 85,369, 2013)</ENT>
                        <ENT>5,122</ENT>
                        <ENT>13.7</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         ESA status: Endangered (E), Threatened (T)/MMPA status: Depleted (D). A dash (-) indicates that the species is not listed under the ESA or designated as depleted under the MMPA. Under the MMPA, a strategic stock is one for which the level of direct human-caused mortality exceeds PBR or which is determined to be declining and likely to be listed under the ESA within the foreseeable future. Any species or stock listed under the ESA is automatically designated under the MMPA as depleted and as a strategic stock.
                    </TNOTE>
                    <TNOTE>
                        <SU>2</SU>
                         NMFS marine mammal stock assessment reports online at: 
                        <E T="03">https://www.fisheries.noaa.gov/national/marine-mammal-protection/marine-mammal-stock-assessment-reports-region/.</E>
                         CV is coefficient of variation; N
                        <E T="0732">min</E>
                         is the minimum estimate of stock abundance. In some cases, CV is not applicable (N/A).
                    </TNOTE>
                    <TNOTE>
                        <SU>3</SU>
                         These values, found in NMFS's SARs, represent annual levels of human-caused mortality plus serious injury from all sources combined (
                        <E T="03">e.g.,</E>
                         commercial fisheries, ship strike). Annual human caused mortality and serious injury (M/SI) often cannot be determined precisely and is in some cases presented as a minimum value or range.
                    </TNOTE>
                    <TNOTE>
                        <SU>4</SU>
                         Information on the classification of marine mammal species can be found on the web page for The Society for Marine Mammalogy's Committee on Taxonomy (
                        <E T="03">https://marinemammalscience.org/science-and-publications/list-marine-mammal-species-subspecies/;</E>
                         Committee on Taxonomy (2022)).
                    </TNOTE>
                </GPOTABLE>
                <P>
                    A detailed description of the species likely to be affected by the construction project, including a brief introduction to the affected stock as well as available information regarding population trends and threats, and information regarding local occurrence, were provided in the 
                    <E T="04">Federal Register</E>
                     notice for the proposed IHA (88 FR 41920, June 28, 2023). Since that time, the structure of the harbor porpoise and humpback whale stocks have been updated; therefore, a detailed description of those species updated stock structure is provided here. Please refer to the 
                    <E T="04">Federal Register</E>
                     notice of the proposed IHA (88 FR 41920, June 28, 2023) for the full description for all species. Please also refer to NMFS' website (
                    <E T="03">https://www.fisheries.noaa.gov/find-species</E>
                    ) for generalized species accounts.
                </P>
                <HD SOURCE="HD2">Harbor Porpoise  </HD>
                <P>
                    In the 2022 Alaska SAR, stock structure was revised for the Southeast Alaska harbor porpoise stock, which was split into three stocks: the Northern Southeast Alaska Inland Waters, Southern Southeast Alaska Inland Waters, and Yakutat/Southeast Alaska Offshore Waters harbor porpoise stocks (Young 
                    <E T="03">et al.,</E>
                     2023). This update better aligns harbor porpoise stock structure with genetics, trends in abundance, and information regarding discontinuous distribution trends (Young 
                    <E T="03">et al.,</E>
                     2023). Harbor porpoises found in Hydaburg are assumed to be members of the Southern Southeast Alaska Inland Waters stock based on the geographical range of the stock, which encompasses Sumner Strait, including areas around Wrangell and Zarembo Islands, Clarence Strait, and adjacent inlets and channels within the inland waters of Southeast Alaska north-northeast of Dixon Entrance.
                </P>
                <HD SOURCE="HD2">Humpback Whale</HD>
                <P>
                    The 2022 Alaska and Pacific SARs include an update to the humpback whale stock structure which modifies the previously MMPA-designated humpback stocks to align more closely with the ESA-designated distinct population segments (DPSs) (Caretta 
                    <E T="03">et al.,</E>
                     2023; Young 
                    <E T="03">et al.,</E>
                     2023). Specifically, the three existing North Pacific humpback whale stocks (Central and Western North Pacific stocks and a CA/OR/WA stock) were replaced by five stocks, largely corresponding with the ESA-designated DPSs. These include Western North Pacific and Hawaii stocks and a Central America/Southern Mexico-CA/OR/WA stock (which corresponds with the Central America DPS). The remaining two stocks, corresponding with the Mexico DPS, are the Mainland Mexico-CA/OR/WA and Mexico-North Pacific stocks (Carretta 
                    <E T="03">et al.,</E>
                     2023; Young 
                    <E T="03">et al.,</E>
                     2023). In the notice of the proposed IHA, NMFS assumed that humpbacks in the proposed action area were members of the Central North Pacific Stock. Based on these new delineations, humpback whales in the proposed action area are now assumed to be members of either the Hawaii stock or the Mexico-North Pacific stock.
                </P>
                <P>
                    The Hawaii stock consists of one demographically independent population (DIP) (Hawaii-Southeast Alaska/Northern British Columbia DIP) and the Hawaii-North Pacific unit, which may or may not be composed of multiple DIPs (Wade 
                    <E T="03">et al.,</E>
                     2021). The DIP and unit are managed as a single stock at this time, due to the lack of data available to separately assess them and lack of compelling conservation benefit to managing them separately (NMFS, 2019; NMFS, 2022b; NMFS 2023). The 
                    <PRTPAGE P="1070"/>
                    DIP is delineated based on two strong lines of evidence: genetics and movement data (Wade 
                    <E T="03">et al.,</E>
                     2021). Whales in the Hawaii-Southeast Alaska/Northern British Columbia DIP winter off Hawaii and largely summer in Southeast Alaska and Northern British Columbia (Wade 
                    <E T="03">et al.,</E>
                     2021). The group of whales that migrate from Russia, western Alaska (Bering Sea and Aleutian Islands), and central Alaska (Gulf of Alaska excluding Southeast Alaska) to Hawaii have been delineated as the Hawaii-North Pacific unit (Wade 
                    <E T="03">et al.,</E>
                     2021). There are a small number of whales that migrate between Hawaii and southern British Columbia/Washington, but current data and analyses do not provide a clear understanding of which unit these whales belong to (Wade 
                    <E T="03">et al.,</E>
                     2021; Caretta 
                    <E T="03">et al.,</E>
                     2023; Young 
                    <E T="03">et al.,</E>
                     2023)
                </P>
                <P>
                    The Hawaii stock of humpback whales is equivalent to the Hawaii DPS of humpback whales, which is not listed under the ESA (Bettridge 
                    <E T="03">et al.,</E>
                     2015; Wade 
                    <E T="03">et al.,</E>
                     2021). Humpback whales were previously considered to be depleted species-wide under the MMPA solely on the basis of the species' ESA listing. After the evaluation of the listing status of DPSs of humpback whales, humpback whale DPSs that are not listed as threatened or endangered were not considered to have depleted status under the MMPA (81 FR 62259, September 8, 2016). However, because the Central North Pacific stock, which is what humpback whales in Hydaburg were presumed to be members of in the notice of the proposed IHA, included some whales from the ESA-listed Mexico and Western North Pacific DPSs, the stock was considered to be endangered and depleted, and as a result, was classified as a strategic stock. The newly defined Hawaii stock of humpback whales does not include whales from any listed DPSs and, therefore, is not currently considered depleted under the MMPA, and is also not a strategic stock due to its ESA status.
                </P>
                <P>
                    The Mexico-North Pacific unit is likely composed of multiple DIPs, based on movement data (Martien 
                    <E T="03">et al.,</E>
                     2021; Wade, 2021, Wade 
                    <E T="03">et al.,</E>
                     2021). However, because currently available data and analyses are not sufficient to delineate or assess DIPs within the unit, it was designated as a single stock (NMFS, 2019; NMFS, 2022c; NMFS, 2023a). Whales in this stock winter off Mexico and the Revillagigedo Archipelago and summer primarily in Alaska waters (Martien 
                    <E T="03">et al.,</E>
                     2021) (Carretta 
                    <E T="03">et al.,</E>
                     2023; Young 
                    <E T="03">et al.,</E>
                     2023). The Mexico-North Pacific stock of humpback whales is one of two stocks that make up the “Mexico DPS” of humpback whales, which are listed as threatened under the ESA (Bettridge 
                    <E T="03">et al.</E>
                     2015; Martien 
                    <E T="03">et al.,</E>
                     2021), and is therefore considered “depleted” and “strategic” under the MMPA.
                </P>
                <HD SOURCE="HD2">Marine Mammal Hearing</HD>
                <P>
                    Hearing is the most important sensory modality for marine mammals underwater, and exposure to anthropogenic sound can have deleterious effects. To appropriately assess the potential effects of exposure to sound, it is necessary to understand the frequency ranges marine mammals are able to hear. Not all marine mammal species have equal hearing capabilities or hear over the same frequency range (
                    <E T="03">e.g.,</E>
                     Richardson 
                    <E T="03">et al.,</E>
                     1995; Wartzok and Ketten, 1999; Au and Hastings, 2008). To reflect this, Southall 
                    <E T="03">et al.</E>
                     (2007, 2019) recommended that marine mammals be divided into hearing groups based on directly measured (behavioral or auditory evoked potential techniques) or estimated hearing ranges (behavioral response data, anatomical modeling, 
                    <E T="03">etc.</E>
                    ). Note that no direct measurements of hearing ability have been successfully completed for mysticetes (
                    <E T="03">i.e.,</E>
                     low-frequency cetaceans). Subsequently, NMFS (2018) described generalized hearing ranges for these marine mammal hearing groups. Generalized hearing ranges were chosen based on the approximately 65 decibel (dB) threshold from the normalized composite audiograms, with the exception for lower limits for low-frequency cetaceans where the lower bound was deemed to be biologically implausible and the lower bound from Southall 
                    <E T="03">et al.</E>
                     (2007) retained. Marine mammal hearing groups and their associated hearing ranges are provided in Table 3.
                </P>
                <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s100,xs72">
                    <TTITLE>Table 3—Marine Mammal Hearing Groups</TTITLE>
                    <TDESC>[NMFS, 2018]</TDESC>
                    <BOXHD>
                        <CHED H="1">Hearing group</CHED>
                        <CHED H="1">Generalized hearing range *</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Low-frequency (LF) cetaceans (baleen whales)</ENT>
                        <ENT>7 Hz to 35 kHz.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Mid-frequency (MF) cetaceans (dolphins, toothed whales, beaked whales, bottlenose whales)</ENT>
                        <ENT>150 Hz to 160 kHz.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            High-frequency (HF) cetaceans (true porpoises, 
                            <E T="03">Kogia,</E>
                             river dolphins, Cephalorhynchid, 
                            <E T="03">Lagenorhynchus cruciger</E>
                             &amp; 
                            <E T="03">L. australis</E>
                            )
                        </ENT>
                        <ENT>275 Hz to 160 kHz.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Phocid pinnipeds (PW) (underwater) (true seals)</ENT>
                        <ENT>50 Hz to 86 kHz.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Otariid pinnipeds (OW) (underwater) (sea lions and fur seals)</ENT>
                        <ENT>60 Hz to 39 kHz.</ENT>
                    </ROW>
                    <TNOTE>
                        * Represents the generalized hearing range for the entire group as a composite (
                        <E T="03">i.e.,</E>
                         all species within the group), where individual species' hearing ranges are typically not as broad. Generalized hearing range chosen based on ~65 dB threshold from normalized composite audiogram, with the exception for lower limits for LF cetaceans (Southall 
                        <E T="03">et al.,</E>
                         2007) and PW pinniped (approximation).
                    </TNOTE>
                </GPOTABLE>
                <P>
                    The pinniped hearing group was modified from Southall 
                    <E T="03">et al.</E>
                     (2007) on the basis of data indicating that phocid species have consistently demonstrated an extended frequency range of hearing compared to otariids, especially in the higher frequency range (Hemilä 
                    <E T="03">et al.,</E>
                     2006; Kastelein 
                    <E T="03">et al.,</E>
                     2009; Reichmuth 
                    <E T="03">et al.,</E>
                     2013).
                </P>
                <P>For more detail concerning these groups and associated generalized hearing ranges, please see NMFS (2018) for a review of available information.</P>
                <HD SOURCE="HD1">Potential Effects of Specified Activities on Marine Mammals and Their Habitat</HD>
                <P>
                    The underwater noise produced by the DOT&amp;PF's construction activities has the potential to result in behavioral harassment of marine mammals in the vicinity of the survey area. The 
                    <E T="04">Federal Register</E>
                     notice of the proposed IHA (88 FR 45774, July 17, 2023) included a discussion of the effects of anthropogenic noise on marine mammals and the potential effects of underwater noise from the DOT&amp;PF' construction activities on marine mammals and their habitat. That information and analysis is incorporated by reference into this final IHA determination and is not repeated here; please refer to the notice of the proposed IHA (88 FR 45774, July 17, 2023).
                    <PRTPAGE P="1071"/>
                </P>
                <HD SOURCE="HD1">Estimated Take</HD>
                <P>This section provides an estimate of the number of incidental takes authorized through the IHA, which will inform both NMFS' consideration of “small numbers,” and the negligible impact determinations.</P>
                <P>Harassment is the only type of take expected to result from these activities. Except with respect to certain activities not pertinent here, section 3(18) of the MMPA defines “harassment” as any act of pursuit, torment, or annoyance, which (i) has the potential to injure a marine mammal or marine mammal stock in the wild (Level A harassment); or (ii) has the potential to disturb a marine mammal or marine mammal stock in the wild by causing disruption of behavioral patterns, including, but not limited to, migration, breathing, nursing, breeding, feeding, or sheltering (Level B harassment).</P>
                <P>
                    Authorized takes will primarily be by Level B harassment, as use of the acoustic source (
                    <E T="03">i.e.,</E>
                     vibratory pile driving, impact pile driving, and DTH systems) has the potential to result in disruption of behavioral patterns for individual marine mammals. There is also some potential for auditory (Level A harassment) to result, primarily for mysticetes and high frequency species and phocids because predicted auditory injury zones are larger than for mid-frequency species and otariids. Auditory injury is unlikely to occur for mid-frequency species or otariids. The mitigation and monitoring measures are expected to minimize the severity of the taking to the extent practicable. As described previously, no serious injury or mortality is anticipated or authorized for this activity. Below we describe how the take numbers are estimated.  
                </P>
                <P>
                    For acoustic impacts, generally speaking, we estimate take by considering: (1) acoustic thresholds above which NMFS believes the best available science indicates marine mammals will be behaviorally harassed or incur some degree of permanent hearing impairment; (2) the area or volume of water that will be ensonified above these levels in a day; (3) the density or occurrence of marine mammals within these ensonified areas; and, (4) the number of days of activities. We note that while these factors can contribute to a basic calculation to provide an initial prediction of potential takes, additional information that can qualitatively inform take estimates is also sometimes available (
                    <E T="03">e.g.,</E>
                     previous monitoring results or average group size). Below, we describe the factors considered here in more detail and present the take estimates.
                </P>
                <HD SOURCE="HD2">Acoustic Thresholds</HD>
                <P>NMFS recommends the use of acoustic thresholds that identify the received level of underwater sound above which exposed marine mammals would be reasonably expected to be behaviorally harassed (equated to Level B harassment) or to incur PTS of some degree (equated to Level A harassment).</P>
                <P>
                    <E T="03">Level B Harassment</E>
                    —Though significantly driven by received level, the onset of behavioral disturbance from anthropogenic noise exposure is also informed to varying degrees by other factors related to the source or exposure context (
                    <E T="03">e.g.,</E>
                     frequency, predictability, duty cycle, duration of the exposure, signal-to-noise ratio, distance to the source), the environment (
                    <E T="03">e.g.,</E>
                     bathymetry, other noises in the area, predators in the area), and the receiving animals (hearing, motivation, experience, demography, life stage, depth) and can be difficult to predict (
                    <E T="03">e.g.,</E>
                     Southall 
                    <E T="03">et al.,</E>
                     2007, 2021, Ellison 
                    <E T="03">et al.,</E>
                     2012). Based on what the available science indicates and the practical need to use a threshold based on a metric that is both predictable and measurable for most activities, NMFS typically uses a generalized acoustic threshold based on received level to estimate the onset of behavioral harassment. NMFS generally predicts that marine mammals are likely to be behaviorally harassed in a manner considered to be Level B harassment when exposed to underwater anthropogenic noise above root-mean-squared pressure received levels (RMS SPL) of 120 dB re 1 μPa for continuous (
                    <E T="03">e.g.,</E>
                     vibratory pile-driving, drilling) and above RMS SPL 160 dB re 1 μPa for non-explosive impulsive (
                    <E T="03">e.g.,</E>
                     seismic airguns) or intermittent (
                    <E T="03">e.g.,</E>
                     scientific sonar) sources. Generally speaking, Level B harassment take estimates based on these behavioral harassment thresholds are expected to include any likely takes by TTS as, in most cases, the likelihood of TTS occurs at distances from the source less than those at which behavioral harassment is likely. TTS of a sufficient degree can manifest as behavioral harassment, as reduced hearing sensitivity and the potential reduced opportunities to detect important signals (conspecific communication, predators, prey) may result in changes in behavior patterns that would not otherwise occur.
                </P>
                <P>The DOT&amp;PF's activity includes the use of continuous (vibratory pile driving) and intermittent (impact pile driving) sources, and therefore the RMS SPL thresholds of 120 and 160 dB re 1 μPa are applicable. DTH systems have both continuous, non-impulsive, and impulsive components. When evaluating Level B harassment, NMFS recommends treating DTH as a continuous source and applying the RMS SPL thresholds of 120 dB re 1 μPa.</P>
                <P>
                    <E T="03">Level A harassment</E>
                    —NMFS' Technical Guidance for Assessing the Effects of Anthropogenic Sound on Marine Mammal Hearing (Version 2.0) (Technical Guidance, 2018) identifies dual criteria to assess auditory injury (Level A harassment) to five different marine mammal groups (based on hearing sensitivity) as a result of exposure to noise from two different types of sources (impulsive or non-impulsive). The DOT&amp;PF's construction includes the use of impulsive (impact pile driving) and non-impulsive (vibratory pile driving) sources. As described above, DTH includes both impulsive and non-impulsive characteristics. When evaluating Level A harassment, NMFS recommends treating DTH as an impulsive source.
                </P>
                <P>
                    The thresholds used to identify the onset of PTS are provided in Table 4. The references, analysis, and methodology used in the development of the thresholds are described in NMFS' 2018 Technical Guidance, which may be accessed at: 
                    <E T="03">www.fisheries.noaa.gov/national/marine-mammal-protection/marine-mammal-acoustic-technical-guidance.</E>
                </P>
                <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s50,r50p,xs100">
                    <TTITLE>Table 4—Thresholds Identifying the Onset of Permanent Threshold Shift</TTITLE>
                    <BOXHD>
                        <CHED H="1">Hearing group</CHED>
                        <CHED H="1">
                            PTS onset acoustic thresholds *
                            <LI>(received level)</LI>
                        </CHED>
                        <CHED H="2">Impulsive</CHED>
                        <CHED H="2">Non-impulsive</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Low-Frequency (LF) Cetaceans</ENT>
                        <ENT>
                            <E T="03">Cell 1: L</E>
                            <E T="0732">pk,flat</E>
                            <E T="03">:</E>
                             219 dB; 
                            <E T="03">L</E>
                            <E T="0732">E,LF,24h</E>
                            <E T="03">:</E>
                             183 dB
                        </ENT>
                        <ENT>
                            <E T="03">Cell 2: L</E>
                            <E T="0732">E,LF,24h</E>
                            <E T="03">:</E>
                             199 dB.
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Mid-Frequency (MF) Cetaceans</ENT>
                        <ENT>
                            <E T="03">Cell 3: L</E>
                            <E T="0732">pk,flat</E>
                            <E T="03">:</E>
                             230 dB; 
                            <E T="03">L</E>
                            <E T="0732">E,MF,24h</E>
                            <E T="03">:</E>
                             185 dB
                        </ENT>
                        <ENT>
                            <E T="03">Cell 4: L</E>
                            <E T="0732">E,MF,24h</E>
                            <E T="03">:</E>
                             198 dB.
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">High-Frequency (HF) Cetaceans</ENT>
                        <ENT>
                            <E T="03">Cell 5: L</E>
                            <E T="0732">pk,flat</E>
                            <E T="03">:</E>
                             202 dB; 
                            <E T="03">L</E>
                            <E T="0732">E,HF,24h</E>
                            <E T="03">:</E>
                             155 dB
                        </ENT>
                        <ENT>
                            <E T="03">Cell 6: L</E>
                            <E T="0732">E,HF,24h</E>
                            <E T="03">:</E>
                             173 dB.
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Phocid Pinnipeds (PW) (Underwater)</ENT>
                        <ENT>
                            <E T="03">Cell 7: L</E>
                            <E T="0732">pk,flat</E>
                            <E T="03">:</E>
                             218 dB; 
                            <E T="03">L</E>
                            <E T="0732">E,PW,24h</E>
                            <E T="03">:</E>
                             185 dB
                        </ENT>
                        <ENT>
                            <E T="03">Cell 8: L</E>
                            <E T="0732">E,PW,24h</E>
                            <E T="03">:</E>
                             201 dB.
                        </ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="1072"/>
                        <ENT I="01">Otariid Pinnipeds (OW) (Underwater)</ENT>
                        <ENT>
                            <E T="03">Cell 9: L</E>
                            <E T="0732">pk,flat</E>
                            <E T="03">:</E>
                             232 dB; 
                            <E T="03">L</E>
                            <E T="0732">E,OW,24h</E>
                            <E T="03">:</E>
                             203 dB
                        </ENT>
                        <ENT>
                            <E T="03">Cell 10: L</E>
                            <E T="0732">E,OW,24h</E>
                            <E T="03">:</E>
                             219 dB.
                        </ENT>
                    </ROW>
                    <TNOTE>* Dual metric acoustic thresholds for impulsive sounds: Use whichever results in the largest isopleth for calculating PTS onset. If a non-impulsive sound has the potential of exceeding the peak sound pressure level thresholds associated with impulsive sounds, these thresholds should also be considered.</TNOTE>
                    <TNOTE>
                        <E T="02">Note:</E>
                         Peak sound pressure (
                        <E T="03">L</E>
                        <E T="0732">pk</E>
                        ) has a reference value of 1 μPa, and cumulative sound exposure level (
                        <E T="03">L</E>
                        <E T="0732">E</E>
                        ) has a reference value of 1μPa
                        <SU>2</SU>
                        s. In this Table, thresholds are abbreviated to reflect American National Standards Institute standards (ANSI 2013). However, peak sound pressure is defined by ANSI as incorporating frequency weighting, which is not the intent for NMFS' 2018 Technical Guidance. Hence, the subscript “flat” is being included to indicate peak sound pressure should be flat weighted or unweighted within the generalized hearing range. The subscript associated with cumulative sound exposure level thresholds indicates the designated marine mammal auditory weighting function (LF, MF, and HF cetaceans, and PW and OW pinnipeds) and that the recommended accumulation period is 24 hours. The cumulative sound exposure level thresholds could be exceeded in a multitude of ways (
                        <E T="03">i.e.,</E>
                         varying exposure levels and durations, duty cycle). When possible, it is valuable for action proponents to indicate the conditions under which these acoustic thresholds will be exceeded.
                    </TNOTE>
                </GPOTABLE>
                <HD SOURCE="HD2">Ensonified Area</HD>
                <P>Here, we describe operational and environmental parameters of the activity that are used in estimating the area ensonified above the acoustic thresholds, including source levels and transmission loss coefficient.</P>
                <P>
                    The sound field in the project area is the existing background noise plus additional construction noise from the project. Marine mammals are expected to be affected via sound generated by the primary components of the project (
                    <E T="03">i.e.,</E>
                     impact pile installation, vibratory pile installation, vibratory pile removal, and DTH).
                </P>
                <P>
                    <E T="03">Sound Source Levels of Construction Activities</E>
                    —The intensity of pile driving sounds is greatly influenced by factors such as the type of piles (material and diameter), hammer type, and the physical environment (
                    <E T="03">e.g.,</E>
                     sediment type) in which the activity takes place (Table 5). A description of the assessment and appropriateness of proxy sound source levels and TL measurements for the DOT&amp;PF's activities can be found in the notice of proposed IHA (88 FR 45774, July 17, 2023). This includes a discussion regarding the analyses of noise from DTH systems that follows NMFS' recommendations (
                    <E T="03">i.e., https://media.fisheries.noaa.gov/2022-11/PUBLIC%20DTH%20Basic%20Guidance_November%202022.pdf;</E>
                     NMFS, 2022a). Please refer to the notice of the proposed IHA (88 FR 45774, July 17, 2023) for full details.
                </P>
                <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s50,r50,12,12,16,r50">
                    <TTITLE>Table 5—Summary of Unattenuated In-Water Pile Driving Proxy Levels</TTITLE>
                    <TDESC>[At 10 m]</TDESC>
                    <BOXHD>
                        <CHED H="1">Pile type</CHED>
                        <CHED H="1">Installation method</CHED>
                        <CHED H="1">
                            Peak SPL
                            <LI>(dB re 1 μPa)</LI>
                        </CHED>
                        <CHED H="1">
                            RMS SPL
                            <LI>(dB re 1 μPa)</LI>
                        </CHED>
                        <CHED H="1">
                            SEL
                            <E T="0732">ss</E>
                            <LI>
                                (dB re 1 μPa
                                <SU>2</SU>
                                 sec)
                            </LI>
                        </CHED>
                        <CHED H="1">
                            Reference
                            <LI>(levels)</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">16-inch steel piles</ENT>
                        <ENT>Vibratory hammer</ENT>
                        <ENT>NA</ENT>
                        <ENT>158</ENT>
                        <ENT>NA</ENT>
                        <ENT>CALTRANS (2020).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">20-inch steel piles</ENT>
                        <ENT>Vibratory hammer</ENT>
                        <ENT>NA</ENT>
                        <ENT>161</ENT>
                        <ENT>NA</ENT>
                        <ENT>Navy (2015).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">24-inch steel piles</ENT>
                        <ENT>Vibratory hammer</ENT>
                        <ENT>NA</ENT>
                        <ENT>161</ENT>
                        <ENT>NA</ENT>
                        <ENT>Navy (2015).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">20-inch steel piles</ENT>
                        <ENT>Impact hammer</ENT>
                        <ENT>208</ENT>
                        <ENT>187</ENT>
                        <ENT>176</ENT>
                        <ENT>CALTRANS (2020).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">24-inch steel piles</ENT>
                        <ENT>Impact hammer</ENT>
                        <ENT>208</ENT>
                        <ENT>193</ENT>
                        <ENT>178</ENT>
                        <ENT>CALTRANS (2020).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8-inch tension anchors</ENT>
                        <ENT>DTH system</ENT>
                        <ENT>170</ENT>
                        <ENT>156</ENT>
                        <ENT>144</ENT>
                        <ENT>Reyff and Heyvaert (2019); Reyff (2020).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">20-inch rock sockets</ENT>
                        <ENT>DTH system</ENT>
                        <ENT>184</ENT>
                        <ENT>167</ENT>
                        <ENT>159</ENT>
                        <ENT>Heyvaert and Reyff (2021).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">24-inch rock sockets</ENT>
                        <ENT>DTH system</ENT>
                        <ENT>184</ENT>
                        <ENT>167</ENT>
                        <ENT>159</ENT>
                        <ENT>Heyvaert and Reyff (2021).</ENT>
                    </ROW>
                    <TNOTE>
                        <E T="02">Notes:</E>
                         NMFS conservatively assumes that noise levels during vibratory pile removal are the same as those during installation for the same type and size pile; all SPLs are unattenuated and represent the SPL referenced at a distance of 10 m from the source; NA = Not applicable; dB re 1 μPa = decibels (dB) referenced to a pressure of 1 micropascal.
                    </TNOTE>
                </GPOTABLE>
                <P>
                    <E T="03">Estimated Harassment Isopleths</E>
                    —All Level B harassment isopleths are reported in Table 7 considering RMS SPLs and the default TL coefficient for practical spreading loss (
                    <E T="03">i.e.,</E>
                     15*Log10(range)). Land forms (including causeways, breakwaters, islands, and other land masses) impede the transmission of underwater sound and create shadows behind them where sound from construction is not audible. At Hydaburg, Level B harassment isopleths from the project will be blocked by Sukkwan Island, Spook Island, Mushroom Island, and the coastline along Prince of Wales Island both southeast and northwest of the project site. The maximum distance that a harassment isopleth can extend due to these land masses is 5,162 m.
                </P>
                <P>
                    The ensonified area associated with Level A harassment is technically challenging to predict due to the need to account for a duration component. Therefore, NMFS developed an optional User Spreadsheet tool to accompany the Technical Guidance (2018) that can be used to relatively simply predict an isopleth distance for use in conjunction with marine mammal density or occurrence to help predict potential takes. We note that because of some of the assumptions included in the methods underlying this optional tool, we anticipate that the resulting isopleth estimates are typically going to be overestimates of some degree, which may result in an overestimate of potential take by Level A harassment. However, this optional tool offers the best way to estimate isopleth distances when more sophisticated modeling methods are not available or practical. For stationary sources (such as from impact pile driving, vibratory pile driving, and DTH), the optional User Spreadsheet tool predicts the distance at which, if a marine mammal remained at that distance for the duration of the activity, it would be expected to incur PTS. Inputs used in the optional User 
                    <PRTPAGE P="1073"/>
                    Spreadsheet tool are reported in Table 6 and the resulting estimated isopleths are reported in Table 7.
                </P>
                <GPOTABLE COLS="9" OPTS="L2,p7,7/8,i1" CDEF="s25,r25,r25,r25,r25,r25,r25,r25,r25">
                    <TTITLE>Table 6—NMFS User Spreadsheet Inputs</TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1">Vibratory pile driving</CHED>
                        <CHED H="2">
                            16-inch steel
                            <LI>piles</LI>
                        </CHED>
                        <CHED H="3">Removal</CHED>
                        <CHED H="2">
                            20-inch steel
                            <LI>piles</LI>
                        </CHED>
                        <CHED H="3">
                            Installation/
                            <LI>removal</LI>
                        </CHED>
                        <CHED H="2">24-inch steel piles</CHED>
                        <CHED H="3">Installation</CHED>
                        <CHED H="3">Removal</CHED>
                        <CHED H="1">Impact pile driving</CHED>
                        <CHED H="2">
                            20-inch steel
                            <LI>piles</LI>
                        </CHED>
                        <CHED H="3">Installation</CHED>
                        <CHED H="2">
                            24-inch steel
                            <LI>piles</LI>
                        </CHED>
                        <CHED H="3">Installation</CHED>
                        <CHED H="1">DTH</CHED>
                        <CHED H="2">20- and 24-inch rock socket</CHED>
                        <CHED H="3">Installation</CHED>
                        <CHED H="2">8-inch tension anchor</CHED>
                        <CHED H="3">Installation</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Spreadsheet Tab Used</ENT>
                        <ENT>A.1) Non-Impul, Stat, Cont</ENT>
                        <ENT>A.1) Non-Impul, Stat, Cont</ENT>
                        <ENT>A.1) Non-Impul, Stat, Cont</ENT>
                        <ENT>A.1) Non-Impul, Stat, Cont</ENT>
                        <ENT>E.1) Impact pile driving</ENT>
                        <ENT>E.1) Impact pile driving</ENT>
                        <ENT>E.2) DTH Systems</ENT>
                        <ENT>A.1) DTH Systems.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Source Level (SPL)</ENT>
                        <ENT>158 dB RMS</ENT>
                        <ENT>161 dB RMS</ENT>
                        <ENT>161 dB RMS</ENT>
                        <ENT>161 dB RMS</ENT>
                        <ENT>176 dB SEL</ENT>
                        <ENT>178 dB SEL</ENT>
                        <ENT>159 dB RMS</ENT>
                        <ENT>144 dB RMS.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Transmission Loss Coefficient</ENT>
                        <ENT>15</ENT>
                        <ENT>15</ENT>
                        <ENT>15</ENT>
                        <ENT>15</ENT>
                        <ENT>15</ENT>
                        <ENT>15</ENT>
                        <ENT>15</ENT>
                        <ENT>15.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Weighting Factor Adjustment (kHz)</ENT>
                        <ENT>2.5</ENT>
                        <ENT>2.5</ENT>
                        <ENT>2.5</ENT>
                        <ENT>2.5</ENT>
                        <ENT>2</ENT>
                        <ENT>2</ENT>
                        <ENT>2</ENT>
                        <ENT>2.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Time to install/remove single pile (minutes)</ENT>
                        <ENT>30</ENT>
                        <ENT>
                            15/30 
                            <SU>1</SU>
                        </ENT>
                        <ENT>
                            15/30 
                            <SU>1</SU>
                        </ENT>
                        <ENT>30</ENT>
                        <ENT/>
                        <ENT/>
                        <ENT>
                            60-480 
                            <SU>2</SU>
                        </ENT>
                        <ENT>
                            60-240.
                            <SU>2</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Number of strikes per pile</ENT>
                        <ENT/>
                        <ENT/>
                        <ENT/>
                        <ENT/>
                        <ENT>50</ENT>
                        <ENT>50</ENT>
                        <ENT>15</ENT>
                        <ENT>15.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Piles per day</ENT>
                        <ENT>2</ENT>
                        <ENT>
                            2/10 
                            <SU>1</SU>
                        </ENT>
                        <ENT>
                            2/10 
                            <SU>1</SU>
                        </ENT>
                        <ENT>2</ENT>
                        <ENT>
                            1/2 
                            <SU>1</SU>
                        </ENT>
                        <ENT>
                            1/2 
                            <SU>1</SU>
                        </ENT>
                        <ENT>1</ENT>
                        <ENT>1.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Distance of sound pressure level measurement (m)</ENT>
                        <ENT>10</ENT>
                        <ENT>10</ENT>
                        <ENT>10</ENT>
                        <ENT>10</ENT>
                        <ENT>10</ENT>
                        <ENT>10</ENT>
                        <ENT>10</ENT>
                        <ENT>10.</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         A maximum scenario was calculated for this activity.
                    </TNOTE>
                    <TNOTE>
                        <SU>2</SU>
                         A range of scenarios was calculated for this activity.
                    </TNOTE>
                </GPOTABLE>
                <GPOTABLE COLS="11" OPTS="L2,p7,7/8,i1" CDEF="s25,r25,r25,10,5,5,5,5,5,10,10">
                    <TTITLE>Table 7—Distances to Level A Harassment, by Hearing Group, and Distances and Areas of Level B Harassment Thresholds per Pile Type and Pile Driving Method</TTITLE>
                    <BOXHD>
                        <CHED H="1">Activity</CHED>
                        <CHED H="1">Pile size</CHED>
                        <CHED H="1">
                            Minutes (min)
                            <LI>or strikes per pile</LI>
                        </CHED>
                        <CHED H="1">
                            Piles
                            <LI>per day</LI>
                        </CHED>
                        <CHED H="1">Level A harassment distance (m)</CHED>
                        <CHED H="2">LF</CHED>
                        <CHED H="2">MF</CHED>
                        <CHED H="2">HF</CHED>
                        <CHED H="2">PW</CHED>
                        <CHED H="2">OW</CHED>
                        <CHED H="1">
                            Level B
                            <LI>harassment</LI>
                            <LI>distance</LI>
                            <LI>(m) all</LI>
                            <LI>hearing</LI>
                            <LI>groups</LI>
                        </CHED>
                        <CHED H="1">
                            Level B
                            <LI>harassment</LI>
                            <LI>area</LI>
                            <LI>
                                (km
                                <SU>2</SU>
                                ) all
                            </LI>
                            <LI>hearing</LI>
                            <LI>groups</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Vibratory Installation</ENT>
                        <ENT>20- and 24-inch</ENT>
                        <ENT>15 min</ENT>
                        <ENT>2</ENT>
                        <ENT>5</ENT>
                        <ENT>1</ENT>
                        <ENT>7</ENT>
                        <ENT>3</ENT>
                        <ENT>1</ENT>
                        <ENT>
                            <SU>3</SU>
                             5,412
                        </ENT>
                        <ENT>
                            <SU>4</SU>
                             4.34
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>
                            30 
                            <SU>1</SU>
                             min
                        </ENT>
                        <ENT>
                            <SU>1</SU>
                             10
                        </ENT>
                        <ENT>20</ENT>
                        <ENT>2</ENT>
                        <ENT>30</ENT>
                        <ENT>13</ENT>
                        <ENT>1</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Vibratory Removal</ENT>
                        <ENT>16-inch</ENT>
                        <ENT>30 min</ENT>
                        <ENT>2</ENT>
                        <ENT>5</ENT>
                        <ENT>1</ENT>
                        <ENT>7</ENT>
                        <ENT>3</ENT>
                        <ENT>1</ENT>
                        <ENT>3,415</ENT>
                        <ENT>3.90</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>24-inch</ENT>
                        <ENT>30 min</ENT>
                        <ENT>2</ENT>
                        <ENT>7</ENT>
                        <ENT>1</ENT>
                        <ENT>11</ENT>
                        <ENT>5</ENT>
                        <ENT>1</ENT>
                        <ENT>
                            <SU>3</SU>
                             5,412
                        </ENT>
                        <ENT>
                            <SU>4</SU>
                             4.34
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Impact Installation</ENT>
                        <ENT>20-inch</ENT>
                        <ENT>50 strikes</ENT>
                        <ENT>1</ENT>
                        <ENT>47</ENT>
                        <ENT>2</ENT>
                        <ENT>56</ENT>
                        <ENT>25</ENT>
                        <ENT>2</ENT>
                        <ENT>1,585</ENT>
                        <ENT>2.14</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>
                            50 
                            <SU>1</SU>
                             strikes
                        </ENT>
                        <ENT>
                            <SU>1</SU>
                             2
                        </ENT>
                        <ENT>74</ENT>
                        <ENT>3</ENT>
                        <ENT>88</ENT>
                        <ENT>40</ENT>
                        <ENT>3</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>24-inch</ENT>
                        <ENT>50 strikes</ENT>
                        <ENT>1</ENT>
                        <ENT>63</ENT>
                        <ENT>3</ENT>
                        <ENT>75</ENT>
                        <ENT>34</ENT>
                        <ENT>3</ENT>
                        <ENT>631</ENT>
                        <ENT>0.65</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>
                            50 
                            <SU>1</SU>
                             strikes
                        </ENT>
                        <ENT>
                            <SU>1</SU>
                             2
                        </ENT>
                        <ENT>100</ENT>
                        <ENT>4</ENT>
                        <ENT>119</ENT>
                        <ENT>54</ENT>
                        <ENT>4</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            DTH (Rock Socket) 
                            <SU>2</SU>
                        </ENT>
                        <ENT>20- and 24-inch</ENT>
                        <ENT>60 min</ENT>
                        <ENT>1</ENT>
                        <ENT>359</ENT>
                        <ENT>13</ENT>
                        <ENT>427</ENT>
                        <ENT>192</ENT>
                        <ENT>14</ENT>
                        <ENT>
                            <SU>3</SU>
                             13,594
                        </ENT>
                        <ENT>
                            <SU>4</SU>
                             4.34
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>120 min</ENT>
                        <ENT>1</ENT>
                        <ENT>569</ENT>
                        <ENT>21</ENT>
                        <ENT>678</ENT>
                        <ENT>305</ENT>
                        <ENT>23</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>80 min</ENT>
                        <ENT>1</ENT>
                        <ENT>746</ENT>
                        <ENT>27</ENT>
                        <ENT>888</ENT>
                        <ENT>399</ENT>
                        <ENT>29</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>240 min</ENT>
                        <ENT>1</ENT>
                        <ENT>903</ENT>
                        <ENT>33</ENT>
                        <ENT>1,076</ENT>
                        <ENT>484</ENT>
                        <ENT>36</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>300 min</ENT>
                        <ENT>1</ENT>
                        <ENT>1,048</ENT>
                        <ENT>38</ENT>
                        <ENT>1,249</ENT>
                        <ENT>561</ENT>
                        <ENT>41</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>360 min</ENT>
                        <ENT>1</ENT>
                        <ENT>1,184</ENT>
                        <ENT>43</ENT>
                        <ENT>1,410</ENT>
                        <ENT>634</ENT>
                        <ENT>47</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>420 min</ENT>
                        <ENT>1</ENT>
                        <ENT>1,312</ENT>
                        <ENT>47</ENT>
                        <ENT>1,563</ENT>
                        <ENT>702</ENT>
                        <ENT>52</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>480 min</ENT>
                        <ENT>1</ENT>
                        <ENT>1,434</ENT>
                        <ENT>51</ENT>
                        <ENT>1,708</ENT>
                        <ENT>768</ENT>
                        <ENT>56</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            DTH (Tension Anchor) 
                            <SU>2</SU>
                        </ENT>
                        <ENT>8-inch</ENT>
                        <ENT>60 min</ENT>
                        <ENT>1</ENT>
                        <ENT>36</ENT>
                        <ENT>2</ENT>
                        <ENT>43</ENT>
                        <ENT>20</ENT>
                        <ENT>2</ENT>
                        <ENT>2,512</ENT>
                        <ENT>3.07</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>120 min</ENT>
                        <ENT>1</ENT>
                        <ENT>57</ENT>
                        <ENT>2</ENT>
                        <ENT>68</ENT>
                        <ENT>31</ENT>
                        <ENT>3</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>180 min</ENT>
                        <ENT>1</ENT>
                        <ENT>75</ENT>
                        <ENT>3</ENT>
                        <ENT>89</ENT>
                        <ENT>40</ENT>
                        <ENT>3</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>240 min</ENT>
                        <ENT>1</ENT>
                        <ENT>91</ENT>
                        <ENT>4</ENT>
                        <ENT>108</ENT>
                        <ENT>4</ENT>
                        <ENT>4</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>300 min</ENT>
                        <ENT>1</ENT>
                        <ENT>105</ENT>
                        <ENT>4</ENT>
                        <ENT>125</ENT>
                        <ENT>57</ENT>
                        <ENT>5</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>360 min</ENT>
                        <ENT>1</ENT>
                        <ENT>119</ENT>
                        <ENT>5</ENT>
                        <ENT>141</ENT>
                        <ENT>64</ENT>
                        <ENT>5</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>420 min</ENT>
                        <ENT>1</ENT>
                        <ENT>132</ENT>
                        <ENT>5</ENT>
                        <ENT>157</ENT>
                        <ENT>71</ENT>
                        <ENT>6</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>480 min</ENT>
                        <ENT>1</ENT>
                        <ENT>144</ENT>
                        <ENT>6</ENT>
                        <ENT>171</ENT>
                        <ENT>77</ENT>
                        <ENT>6</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         A maximum scenario was calculated for this activity.
                    </TNOTE>
                    <TNOTE>
                        <SU>2</SU>
                         A range of scenarios was calculated for this activity.
                    </TNOTE>
                    <TNOTE>
                        <SU>3</SU>
                         Harassment distances will be truncated where appropriate to account for land masses, to a maximum distance of 5,162 m.
                    </TNOTE>
                    <TNOTE>
                        <SU>4</SU>
                         Harassment areas are truncated where appropriate to account for land masses, to a maximum area of 4.34 km
                        <SU>2</SU>
                        .
                    </TNOTE>
                </GPOTABLE>
                <PRTPAGE P="1074"/>
                <HD SOURCE="HD2">Marine Mammal Occurrence and Take Estimation</HD>
                <P>In this section we provide information about the occurrence of marine mammals, including density or other relevant information that will inform the take calculations. We also describe how this information is synthesized to produce a quantitative estimate of the take that is reasonably likely to occur and is authorized. Although construction is currently planned to begin in fall 2023, unexpected delays associated with construction can occur. To account for this uncertainty, the following exposure estimates assume that construction will occur during the periods of peak abundance for those species for which abundance varies seasonally.</P>
                <HD SOURCE="HD2">Steller Sea Lion</HD>
                <P>No density or abundance numbers exist for Steller sea lions in the action area, and they are not known to regularly occur near Hydaburg. However, in context of a lack of local data, the DOT&amp;PF conservatively estimated that during peak salmon runs, 6 groups of 10 individuals could be exposed to project-related underwater noise each week during pile installation and removal activities, for a total of 240 exposures (4 weeks * 60 sea lions per week = 240 total exposures).</P>
                <P>The largest Level A harassment zone for Steller sea lions is 59 m (Table 7). Due to the small Level A harassment zones (Table 7) and the implementation of shutdown zones, which will be larger than Level A harassment zones (described below in the Mitigation section), NMFS has determined that take by Level A harassment is not anticipated for Steller sea lions. Therefore, NMFS authorizes all 240 estimated exposures as takes by Level B harassment. Takes by Level A harassment for Steller sea lions are not authorized.</P>
                <HD SOURCE="HD2">Harbor Seal</HD>
                <P>Up to six known harbor seal haulouts are located near the project area; however, they are all located outside of the estimated harassment zones, with the closest haulout located just over 4.5 km southeast of the project site, but blocked by a land shadow (see Figure 4-2 in the DOT&amp;PF's application). Within the project area, harbor seals remain relatively rare as described by local residents. The DOT&amp;PF conservatively estimated that up to 8 harbor seals could be within estimated harassment zones each day during pile installation and removal activities, for a total of 208 exposures (26 days * 8 seals per day = 208 total exposures).</P>
                <P>
                    The largest Level A harassment zone for harbor seals is 768 m (Table 7). There are no known harbor seal haulouts within this distance, however, it is possible that harbor seals may approach and enter within this distance for sufficient duration to incur PTS. Further, the largest practicable shutdown zone that the DOT&amp;PF can implement for harbor seals is 400 m (described below in the Mitigation section). To account for this difference, NMFS authorizes additional takes by Level A harassment, as compared with the DOT&amp;PF's request of 48 takes by Level A harassment, which assumed smaller Level A harassment isopleths based on their assessment of DTH systems. Additional takes were determined by calculating the ratio of the largest Level A harassment area for 20- and 24-inch (50.8- and 60.96-cm) DTH activities (
                    <E T="03">i.e.,</E>
                     0.89 km
                    <SU>2</SU>
                     for a Level A harassment distance of 768 m) minus the area of the shutdown zone for harbor seals (
                    <E T="03">i.e.,</E>
                     0.27 km
                    <SU>2</SU>
                     for a shutdown zone distance of 400 m) to the area of the Level B harassment isopleth (4.34 km
                    <SU>2</SU>
                     for a Level B harassment distance of 5,162 m) (
                    <E T="03">i.e.,</E>
                     (0.89 km
                    <SU>2</SU>
                    −0.27 km
                    <SU>2</SU>
                    )/4.34 km
                    <SU>2</SU>
                     = 0.14). We then multiplied this ratio by the total number of estimated harbor seal exposures to determine additional take by Level A harassment (
                    <E T="03">i.e.,</E>
                     0.14 * 208 exposures = 29.12 takes, rounded up to 30 takes). The total take by Level A harassment was then calculated as the take originally requested by the DOT&amp;PF plus the additional take calculated by NMFS (
                    <E T="03">i.e.,</E>
                     48 + 30), for a total of 78 takes by Level A harassment. Takes by Level B harassment were calculated as the number of estimated harbor seal exposures minus the amount of take by Level A harassment (
                    <E T="03">i.e.,</E>
                     208−78). Therefore, NMFS authorizes 78 takes by Level A harassment and 130 takes by Level B harassment for harbor seals, for a total of 208 takes.
                </P>
                <HD SOURCE="HD2">Northern Elephant Seal</HD>
                <P>Northern elephant seal abundance throughout coastal southeast Alaska is low, and anecdotal reports have not included northern elephant seals near the project area. However, northern elephant seals have been observed elsewhere in southeast Alaska; therefore, this species could occur near the project area. To account for this possibility, the DOT&amp;PF estimated that one northern elephant seal could be within estimated harassment zones each week during pile installation and removal activities, for a total of four exposures (4 weeks * 1 northern elephant seal each week = 4 total exposures).</P>
                <P>
                    The largest practicable shutdown zone the DOT&amp;PF can implement for northern elephant seals (400 m) (described below in the Mitigation section) is smaller than the Level A harassment isopleths that result from 240 or minutes more of 20- and 24-inch (50.8- and 60.96-cm) DTH rock socket installation (Table 7). To account for this difference, NMFS followed the same method as described above for harbor seals to calculate take by Level A harassment for northern elephant seals. This was achieved by calculating the ratio of the largest Level A harassment area for 20- and 24-inch (50.8- and 60.96-cm) DTH activities (
                    <E T="03">i.e.,</E>
                     0.89 km
                    <SU>2</SU>
                     for a Level A harassment distance of 768 m) minus the area of the shutdown zone for elephant seals (
                    <E T="03">i.e.,</E>
                     0.27 km
                    <SU>2</SU>
                     for a shutdown zone distance of 400 m) to the area of the Level B harassment isopleth (4.34 km
                    <SU>2</SU>
                     for a Level B harassment distance of 5,162 m) (
                    <E T="03">i.e.,</E>
                     (0.89 km
                    <SU>2</SU>
                    −0.27 km
                    <SU>2</SU>
                    )/4.34 km
                    <SU>2</SU>
                     = 0.14), and by multiplying this ratio by the total number of estimated northern elephant seal exposures (
                    <E T="03">i.e.,</E>
                     0.14 * 4 exposures = 0.56 takes, rounded up to 1 take by Level A harassment). Takes by Level B harassment were calculated as the number of estimated northern elephant exposures minus the amount of authorized take by Level A harassment (
                    <E T="03">i.e.,</E>
                     4−1). Therefore, NMFS authorizes one take by Level A harassment and three takes by Level B harassment for northern elephant seals, for a total of four takes.
                </P>
                <HD SOURCE="HD2">Harbor Porpoise</HD>
                <P>There have been no systematic studies or observations of harbor porpoises specific to Hydaburg or Sukkwan Strait, and sightings of harbor porpoises have not been described in this region by local residents. As such, there is limited potential for them to occur in the project area, but they could occur in low numbers as individuals have been observed in southern inland waters of southeast Alaska. Therefore, the DOT&amp;PF estimated that up to two harbor porpoises could be within estimated harassment zones each day during pile installation and removal activities, for a total of 52 exposures (26 days * 2 porpoises per day = 52 exposures).</P>
                <P>
                    Harbor porpoises are small, lack a visible blow, have low dorsal fins, an overall low profile, and a short surfacing time, making them difficult to observe (Dahlheim 
                    <E T="03">et al.,</E>
                     2015). These characteristics likely reduce the identification and reporting of this species. For these reasons, and based off 
                    <PRTPAGE P="1075"/>
                    of their assessment of DTH systems, the DOT&amp;PF requested that eight takes by Level A harassment be authorized for harbor porpoises (4 weeks * 2 harbor porpoise per week = 8 takes by Level A harassment).
                </P>
                <P>
                    The maximum Level A harassment isopleth estimated by NMFS for harbor porpoises is 1,708 m, which is larger than what the DOT&amp;PF analyzed. The largest practicable shutdown zone that the DOT&amp;PF can implement for harbor porpoises is 500 m (described below in the Mitigation section). To account for this difference and the increased possibility of harbor porpoises occurring outside of the shutdown zone and in the Level A harassment zone long enough to incur PTS, NMFS authorizes additional takes by Level A harassment, as compared with the DOT&amp;PF's request. Additional takes were determined by calculating the ratio of the largest Level A harassment area for 20- and 24-inch (50.8- and 60.96-cm) DTH activities (
                    <E T="03">i.e.,</E>
                     2.25 km
                    <SU>2</SU>
                     for a Level A harassment distance of 1,708 m minus the area of the shutdown zone for harbor porpoises (
                    <E T="03">i.e.,</E>
                     0.42 km
                    <SU>2</SU>
                     for a shutdown zone distance of 500 m) to the area of the Level B harassment isopleth (4.34 km
                    <SU>2</SU>
                     for a Level B harassment distance of 5,162 m) (
                    <E T="03">i.e.,</E>
                     (2.25 km
                    <SU>2</SU>
                    −0.42 km
                    <SU>2</SU>
                    )/4.34 km
                    <SU>2</SU>
                     = 0.42). We then multiplied this ratio by the total number of estimated harbor porpoise exposures to determine additional take by Level A harassment (
                    <E T="03">i.e.,</E>
                     0.42 * 8 exposures = 3.36 takes, rounded up to 4 takes). The total take by Level A harassment was then calculated as the take originally requested by the DOT&amp;PF plus the additional take calculated by NMFS (
                    <E T="03">i.e.,</E>
                     8 + 4), for a total of 12 takes by Level A harassment. Takes by Level B harassment were calculated as the number of estimated harbor porpoise exposures minus the amount of take by Level A harassment (
                    <E T="03">i.e.,</E>
                     52−12). Therefore, NMFS authorizes 12 takes by Level A harassment and 40 takes by Level B harassment for harbor seals, for a total of 52 takes.
                </P>
                <HD SOURCE="HD2">Dall's Porpoise</HD>
                <P>Dall's porpoises are not expected to occur in Sukkwan Strait because the shallow water habitat of the bay is atypical of areas where Dall's porpoises usually occur. However, recent research indicates that Dall's porpoises may opportunistically exploit nearshore habitats where predators, such as killer whales, are absent. Therefore, the DOT&amp;PF anticipates that one large Dall's porpoise pod (15 individuals) could be within the estimated harassment zones during in-water construction, for a total of 15 possible exposures.</P>
                <P>
                    Dall's porpoises typically appear in larger groups and exhibit behaviors that make them more visible and thus easier to observe at distance. Based on this assumption, the DOT&amp;PF did not request any takes by Level A harassment for this species. However, the maximum Level A harassment zone is 1,708 m, which is larger than what the DOT&amp;PF analyzed. The largest practicable shutdown zone that the DOT&amp;PF can implement for Dall's porpoises during this project is 500 m (described below in the Mitigation section). To account for this difference and the increased possibility of Dall's porpoises occurring outside of the shutdown zone and in the Level A harassment zones for sufficient duration to incur PTS, NMFS adds takes by Level A harassment, as compared with the DOT&amp;PF's request. Because Dall's porpoises typically occur in groups, NMFS authorizes 15 takes (
                    <E T="03">i.e.,</E>
                     one large pod) by Level A harassment in addition to the 15 takes by Level B harassment that the DOT&amp;PF requested, for a total of 30 takes. This will help to ensure that the DOT&amp;PF have enough takes to account for the possibility of one large pod occurring in either the Level A or the Level B harassment zone.
                </P>
                <HD SOURCE="HD2">Pacific White-Sided Dolphin</HD>
                <P>Pacific white-sided dolphins do not generally occur in the shallow, inland waterways of southeast Alaska. There are no records of this species occurring in Sukkwan Strait, and it is uncommon for individuals to occur in the project area. However, recent fluctuations in distribution and abundance decrease the certainty in this prediction. Therefore, the DOT&amp;PF conservatively estimated that one large group (92 individuals) of Pacific white-sided dolphins could be within estimated harassment zones during the in-water construction.</P>
                <P>The largest Level A harassment zone estimated by NMFS for Pacific white-sided dolphins is 51 m. Due to the small Level A harassment zones (Table 7) and the implementation of shutdown zones, which will be larger than Level A harassment zones (described below in the Mitigation section), take by Level A harassment is not anticipated for Pacific white-sided dolphins. Therefore, NMFS authorizes all 92 estimated exposures as takes by Level B harassment. Takes by Level A harassment for Pacific white-sided dolphins are not authorized.</P>
                <HD SOURCE="HD2">Killer Whale</HD>
                <P>Killer whales are observed infrequently throughout Sukkwan Strait, and their presence near Hydaburg is unlikely. However, anecdotal local information suggests that a pod may be seen in the project area every few months. Therefore, the DOT&amp;PF estimate that one killer whale pod of up to 15 individuals may be within estimated harassment zones once during the pile installation and removal activities (15 total exposures).</P>
                <P>The largest Level A harassment zone for killer whales is 51 m (Table 7). Because killer whales are unlikely to enter Sukkwan Strait and are relatively conspicuous, it is unlikely they will approach this distance for sufficient duration to incur PTS. Due to the small Level A harassment zones (Table 7) and the implementation of shutdown zones, which will be larger than Level A harassment zones (described below in the Mitigation section), take by Level A harassment is not anticipated for killer whales. Therefore, NMFS authorizes all 15 estimated exposures as takes by Level B harassment. Takes by Level A harassment for killer whales are not authorized.</P>
                <HD SOURCE="HD2">Humpback Whale</HD>
                <P>Use of Sukkwan Strait by humpback whales is common but intermittent and dependent on the presence of prey fish. Based on anecdotal evidence from local residents, the DOT&amp;PF predicts that four groups of two whales, up to eight individuals per week, may be within estimated harassment zones each week during the 4 weeks of the pile installation and removal activities, for a total of 32 exposures (8 per week * 4 weeks = 32 total exposures). Wade (2021) estimated that approximately 2.4 percent of humpback whales in southeast Alaska are members of the Mexico-North Pacific stock, while all others are members of the Hawaii stock. Therefore, the DOT&amp;PF estimates that 1 of the exposures (32 whales * 0.024 = 0.77 rounded up to 1) will be of an individual from the Mexico stock individuals and 31 exposures will be of individuals from the Hawaii stock.</P>
                <P>Due to the long duration of DTH piling that is anticipated, and the potential for humpback whales to enter the Level A harassment zones from around obstructions or landforms near the project area, the DOT&amp;PF requested that NMFS authorize 4 takes by Level A harassment (equivalent to two groups of two individuals) of humpback whales. Due to the small percentage of humpback whales that may belong to the Mexico-North Pacific stock in southeast Alaska, the DOT&amp;PF assumes that all takes by Level A harassment will be attributed to Hawaii DPS whales.</P>
                <P>
                    The largest Level A harassment zone for humpback whales is 1,435 m (Table 7), which is larger than what the 
                    <PRTPAGE P="1076"/>
                    DOT&amp;PF analyzed. The largest practicable shutdown zone that the DOT&amp;PF can implement for humpback whales during this project is 1,000 m (described below in the Mitigation section). To account for this difference and the increased possibility of humpback whales occurring outside of the shutdown zone and in the Level A harassment zone long enough to incur PTS, NMFS added additional takes by Level A harassment, compared with the DOT&amp;PF's request.
                </P>
                <P>
                    NMFS calculated additional takes by Level A harassment by determining the ratio of the largest Level A harassment area for 20- and 24-inch (50.8- and 60.96-cm) DTH activities (
                    <E T="03">i.e.,</E>
                     2.01 km
                    <SU>2</SU>
                     for a Level A harassment distance of 1,435 m) minus the area of the shutdown zone for humpback whales (
                    <E T="03">i.e.,</E>
                     1.34 km
                    <SU>2</SU>
                     for a shutdown zone distance of 1,000 m) to the area of the Level B harassment isopleth (4.34 km
                    <SU>2</SU>
                     for a Level B harassment distance of 5,162 m) (
                    <E T="03">i.e.,</E>
                     (2.01 km
                    <SU>2</SU>
                    −1.34 km
                    <SU>2</SU>
                    )/4.34 km
                    <SU>2</SU>
                     = 0.15). We then multiplied this ratio by the total number of estimated humpback whales exposures to determine additional take by Level A harassment (
                    <E T="03">i.e.,</E>
                     0.15 * 32 exposures = 4.80 takes, rounded up to 5 takes). The total take by Level A harassment was then calculated as the take originally requested by the DOT&amp;PF plus the additional take calculated by NMFS (
                    <E T="03">i.e.,</E>
                     4 + 5), for a total of 9 takes by Level A harassment. Takes by Level B harassment were calculated as the number of estimated humpback whale exposures minus the amount of take by Level A harassment (
                    <E T="03">i.e.,</E>
                     32−9). Therefore, NMFS authorizes 9 takes by Level A harassment and 23 takes by Level B harassment for humpback whales, for a total of 32 takes. Given that approximately 2.4 percent of humpback whales in southeast Alaska are members of the Mexico-North Pacific stock, NMFS assumes that one of the takes by Level B harassment may be attributed to a humpback whale from the Mexico-North Pacific stock (32 * 2.4 percent = 0.77, rounded up to 1 take). All other takes by Level B harassment and all takes by Level A harassment (
                    <E T="03">i.e.,</E>
                     31) are assumed to be attributed to humpback whales from the Hawaii stock.
                </P>
                <HD SOURCE="HD2">Minke Whale</HD>
                <P>Minke whale abundance throughout southeast Alaska is low, and anecdotal reports have not included minke whales near the project area. However, minke whales are distributed throughout a wide variety of habitats and have been observed elsewhere in southeast Alaska; therefore, this species could occur near the project area. NMFS has previously estimated that three individual minke whales could occur near Metlakatla every 4 months during a similar activity (86 FR 43190, August 6, 2021). Therefore, DOT&amp;PF conservatively estimated that up to three minke whales may be exposed to project-related underwater noise during the pile installation and removal activities.</P>
                <P>Due to the low likelihood of minke whale occurrence near the project site, the DOT&amp;PF did not request any takes by Level A harassment for this species. However, the maximum Level A harassment isopleth estimated by NMFS for minke whales is 1,435 m, which is larger than what the DOT&amp;PF analyzed. The largest practicable shutdown zone that the DOT&amp;PF can implement for minke whales during this project is 1,000 m (described below in the Mitigation section). To account for this difference and the increased possibility of minke whales occurring outside of the shutdown zone and within the Level A harassment zone long enough to incur PTS, NMFS added takes by Level A harassment to the DOT&amp;PF's request.</P>
                <P>
                    NMFS calculated additional takes by Level A harassment by determining the ratio of the largest Level A harassment area for 20- and 24-inch (50.8- and 60.69-cm) DTH activities (
                    <E T="03">i.e.,</E>
                     2.01 km
                    <SU>2</SU>
                     for a Level A harassment distance of 1,435 m) minus the area of the shutdown zone for minke whales (
                    <E T="03">i.e.,</E>
                     1.34 km
                    <SU>2</SU>
                     for a shutdown zone distance of 1,000 m) to the area of the Level B harassment isopleth (4.34 km
                    <SU>2</SU>
                    ) for a Level B harassment distance of 5,162 m) (
                    <E T="03">i.e.,</E>
                     (2.01 km
                    <SU>2</SU>
                    −1.34 km
                    <SU>2</SU>
                    )/4.34 km
                    <SU>2</SU>
                     = 0.15). We then multiplied this ratio by the total number of estimated minke whales exposures to determine take by Level A harassment (
                    <E T="03">i.e.,</E>
                     0.15 * 3 exposures = 0.45 takes, rounded up to 1 take by Level A harassment). Takes by Level B harassment were calculated as the number of estimated minke whale exposures minus the amount of take by Level A harassment (
                    <E T="03">i.e.,</E>
                     3−1). Therefore, NMFS authorizes one take by Level A harassment and two takes by Level B harassment for minke whales, for a total of three takes.
                </P>
                <P>In summary, the total amount of takes by Level A harassment and Level B harassment authorized for each marine mammal stock is presented in Table 8.</P>
                <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s50,r50,12,12,12,12">
                    <TTITLE>Table 8—Amount of Authorized Take as a Percentage of Stock Abundance, by Stock and Harassment Type</TTITLE>
                    <BOXHD>
                        <CHED H="1">Species</CHED>
                        <CHED H="1">Stock or DPS</CHED>
                        <CHED H="1">Authorized take</CHED>
                        <CHED H="2">Level A</CHED>
                        <CHED H="2">Level B</CHED>
                        <CHED H="2">Total</CHED>
                        <CHED H="1">
                            Percent 
                            <LI>of stock</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Steller sea lion</ENT>
                        <ENT>Eastern</ENT>
                        <ENT>0</ENT>
                        <ENT>240</ENT>
                        <ENT>240</ENT>
                        <ENT>0.56</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Harbor seals</ENT>
                        <ENT>Dixon/Cape Decision</ENT>
                        <ENT>78</ENT>
                        <ENT>130</ENT>
                        <ENT>208</ENT>
                        <ENT>0.89</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Northern elephant seals</ENT>
                        <ENT>CA Breeding</ENT>
                        <ENT>1</ENT>
                        <ENT>3</ENT>
                        <ENT>4</ENT>
                        <ENT>&lt;0.01</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Harbor porpoises</ENT>
                        <ENT>Southern Southeast Alaska Inland Waters</ENT>
                        <ENT>12</ENT>
                        <ENT>40</ENT>
                        <ENT>52</ENT>
                        <ENT>5.84</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Dall's porpoises</ENT>
                        <ENT>Alaska</ENT>
                        <ENT>15</ENT>
                        <ENT>15</ENT>
                        <ENT>30</ENT>
                        <ENT>
                            <SU>1</SU>
                             UNK
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Pacific white-sided dolphins</ENT>
                        <ENT>N Pacific</ENT>
                        <ENT>0</ENT>
                        <ENT>92</ENT>
                        <ENT>92</ENT>
                        <ENT>0.34</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Killer whales</ENT>
                        <ENT>Eastern North Pacific Alaska Resident</ENT>
                        <ENT>0</ENT>
                        <ENT>15</ENT>
                        <ENT>15</ENT>
                        <ENT>
                            <SU>2</SU>
                             0.78
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl">Eastern Northern Pacific Northern Resident.</ENT>
                        <ENT O="xl"/>
                        <ENT O="xl"/>
                        <ENT O="xl"/>
                        <ENT>
                            <SU>2</SU>
                             4.97
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl">West Coast Transient.</ENT>
                        <ENT O="xl"/>
                        <ENT O="xl"/>
                        <ENT O="xl"/>
                        <ENT>
                            <SU>3</SU>
                             4.30
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Humpback whales</ENT>
                        <ENT>Hawaii</ENT>
                        <ENT>9</ENT>
                        <ENT>23</ENT>
                        <ENT>32</ENT>
                        <ENT>
                            <SU>2</SU>
                             0.28
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl">Mexico-North Pacific.</ENT>
                        <ENT O="xl"/>
                        <ENT O="xl"/>
                        <ENT O="xl"/>
                        <ENT>
                            <E T="0731">1 2</E>
                             UNK
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Minke whales</ENT>
                        <ENT>Alaska</ENT>
                        <ENT>1</ENT>
                        <ENT>2</ENT>
                        <ENT>3</ENT>
                        <ENT/>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         NMFS does not have an official abundance estimate for this stock; please refer to the Small Numbers section of this notice for a discussion regarding the percentage of this stock authorized for take.
                    </TNOTE>
                    <TNOTE>
                        <SU>2</SU>
                         NMFS conservatively assumes that all takes occur to each stock.
                    </TNOTE>
                </GPOTABLE>
                <PRTPAGE P="1077"/>
                <HD SOURCE="HD1">Mitigation</HD>
                <P>In order to issue an IHA under section 101(a)(5)(D) of the MMPA, NMFS must set forth the permissible methods of taking pursuant to the activity, and other means of effecting the least practicable impact on the species or stock and its habitat, paying particular attention to rookeries, mating grounds, and areas of similar significance, and on the availability of the species or stock for taking for certain subsistence uses (latter not applicable for this action). NMFS regulations require applicants for incidental take authorizations to include information about the availability and feasibility (economic and technological) of equipment, methods, and manner of conducting the activity or other means of effecting the least practicable adverse impact upon the affected species or stocks, and their habitat (50 CFR 216.104(a)(11)).</P>
                <P>In evaluating how mitigation may or may not be appropriate to ensure the least practicable adverse impact on species or stocks and their habitat, as well as subsistence uses where applicable, NMFS considers two primary factors:</P>
                <P>(1) The manner in which, and the degree to which, the successful implementation of the measure(s) is expected to reduce impacts to marine mammals, marine mammal species or stocks, and their habitat. This considers the nature of the potential adverse impact being mitigated (likelihood, scope, range). It further considers the likelihood that the measure will be effective if implemented (probability of accomplishing the mitigating result if implemented as planned), the likelihood of effective implementation (probability implemented as planned); and</P>
                <P>(2) The practicability of the measures for applicant implementation, which may consider such things as cost, and impact on operations.  </P>
                <P>The DOT&amp;PF must employ the following standard mitigation measures, as included in the IHA:</P>
                <P>• Ensure that construction supervisors and crews, the monitoring team and relevant DOT&amp;PF staff are trained prior to the start of all pile driving and DTH activity, so that responsibilities, communication procedures, monitoring protocols, and operational procedures are clearly understood. New personnel joining during the project must be trained prior to commencing work;</P>
                <P>• Avoid direct physical interaction with marine mammals during construction activity. If a marine mammal comes within 10 m of such activity, operations shall cease. Should a marine mammal come within 10 m of a vessel in transit, the boat operator will reduce vessel speed to the minimum level required to maintain steerage and safe working conditions. If human safety is at risk, the in-water activity will be allowed to continue until it is safe to stop;</P>
                <P>• Employ PSOs and establish monitoring locations as described in Section 5 of the IHA. The DOT&amp;PF must monitor the project area to the maximum extent possible based on the required number of PSOs, required monitoring locations, and environmental conditions. For all pile driving and DTH activities at least two PSOs must be used;</P>
                <P>• For all pile driving/removal activities, a minimum 30 m shutdown zone must be established. The purpose of a shutdown zone is generally to define an area within which shutdown of activity will occur upon sighting of a marine mammal (or in anticipation of an animal entering the defined area). Shutdown zones will vary based on the type of driving/removal activity type and by marine mammal hearing group (see Table 9). Here, shutdown zones are larger than or equivalent to the calculated Level A harassment isopleths shown in Table 7, except when indicated due to practicability and effectiveness concerns. These concerns include the limited viewpoints available to station PSOs along Sukkwan Strait, the presence of landmasses that may obstruct viewpoints, and decreased effectiveness in sighting marine mammals at increased distances. Further, shutdown zones at greater distances than those in Table 9 will likely result in the DOT&amp;PFs activities being shut down more frequently than is practicable for them to maintain their project schedule;</P>
                <GPOTABLE COLS="9" OPTS="L2,p7,7/8,i1" CDEF="s50,r50,r50,8,8,8,8,8,8">
                    <TTITLE>Table 9—Shutdown Zones During Project Activities</TTITLE>
                    <BOXHD>
                        <CHED H="1">Activity</CHED>
                        <CHED H="1">Pile size</CHED>
                        <CHED H="1">
                            Minutes (min)
                            <LI>or strikes per pile</LI>
                        </CHED>
                        <CHED H="1">
                            Piles
                            <LI>per day</LI>
                        </CHED>
                        <CHED H="1">Shutdown zone (m)</CHED>
                        <CHED H="2">LF</CHED>
                        <CHED H="2">MF</CHED>
                        <CHED H="2">HF</CHED>
                        <CHED H="2">PW</CHED>
                        <CHED H="2">OW</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Vibratory Installation</ENT>
                        <ENT>20- and 24-inch</ENT>
                        <ENT>≤30 min</ENT>
                        <ENT>≤10</ENT>
                        <ENT>30</ENT>
                        <ENT>30</ENT>
                        <ENT>30</ENT>
                        <ENT>30</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Vibratory Removal</ENT>
                        <ENT>16- and 24-inch</ENT>
                        <ENT>30 min</ENT>
                        <ENT>2</ENT>
                        <ENT>30</ENT>
                        <ENT>30</ENT>
                        <ENT>30</ENT>
                        <ENT>30</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Impact Installation</ENT>
                        <ENT>20-inch</ENT>
                        <ENT>50 strikes</ENT>
                        <ENT>1</ENT>
                        <ENT>50</ENT>
                        <ENT>30</ENT>
                        <ENT>60</ENT>
                        <ENT>30</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>50 strikes</ENT>
                        <ENT>2</ENT>
                        <ENT>80</ENT>
                        <ENT>30</ENT>
                        <ENT>90</ENT>
                        <ENT>
                            <SU>1</SU>
                             40
                        </ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>24-inch</ENT>
                        <ENT>50 strikes</ENT>
                        <ENT>1</ENT>
                        <ENT>70</ENT>
                        <ENT>30</ENT>
                        <ENT>80</ENT>
                        <ENT>40</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>50 strikes</ENT>
                        <ENT>2</ENT>
                        <ENT>
                            <SU>1</SU>
                             100
                        </ENT>
                        <ENT>30</ENT>
                        <ENT>120</ENT>
                        <ENT>60</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">DTH (Rock Socket)</ENT>
                        <ENT>20- and 24-inch</ENT>
                        <ENT>60 min</ENT>
                        <ENT>1</ENT>
                        <ENT>360</ENT>
                        <ENT>30</ENT>
                        <ENT>430</ENT>
                        <ENT>200</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>120 min</ENT>
                        <ENT>1</ENT>
                        <ENT>570</ENT>
                        <ENT>30</ENT>
                        <ENT>
                            <SU>2</SU>
                             500
                        </ENT>
                        <ENT>310</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>180 min</ENT>
                        <ENT>1</ENT>
                        <ENT>750</ENT>
                        <ENT>30</ENT>
                        <ENT>
                            <SU>2</SU>
                             500
                        </ENT>
                        <ENT>400</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>240 min</ENT>
                        <ENT>1</ENT>
                        <ENT>1,000</ENT>
                        <ENT>40</ENT>
                        <ENT>
                            <SU>2</SU>
                             500
                        </ENT>
                        <ENT>
                            <SU>2</SU>
                             400
                        </ENT>
                        <ENT>40</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>300 min</ENT>
                        <ENT>1</ENT>
                        <ENT>
                            <SU>2</SU>
                             1,000
                        </ENT>
                        <ENT>40</ENT>
                        <ENT>
                            <SU>2</SU>
                             500
                        </ENT>
                        <ENT>
                            <SU>2</SU>
                             400
                        </ENT>
                        <ENT>50</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>360 min</ENT>
                        <ENT>1</ENT>
                        <ENT>
                            <SU>2</SU>
                             1,000
                        </ENT>
                        <ENT>50</ENT>
                        <ENT>
                            <SU>2</SU>
                             500
                        </ENT>
                        <ENT>
                            <SU>2</SU>
                             400
                        </ENT>
                        <ENT>50</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>420 min</ENT>
                        <ENT>1</ENT>
                        <ENT>
                            <SU>2</SU>
                             1,000
                        </ENT>
                        <ENT>50</ENT>
                        <ENT>
                            <SU>2</SU>
                             500
                        </ENT>
                        <ENT>
                            <SU>2</SU>
                             400
                        </ENT>
                        <ENT>60</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>480 min</ENT>
                        <ENT>1</ENT>
                        <ENT>
                            <SU>2</SU>
                             1,000
                        </ENT>
                        <ENT>60</ENT>
                        <ENT>
                            <SU>2</SU>
                             500
                        </ENT>
                        <ENT>
                            <SU>2</SU>
                             400
                        </ENT>
                        <ENT>60</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">DTH (Tension Anchor)</ENT>
                        <ENT>8-inch</ENT>
                        <ENT>60 min</ENT>
                        <ENT>1</ENT>
                        <ENT>40</ENT>
                        <ENT>30</ENT>
                        <ENT>50</ENT>
                        <ENT>30</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>120 min</ENT>
                        <ENT>1</ENT>
                        <ENT>60</ENT>
                        <ENT>30</ENT>
                        <ENT>70</ENT>
                        <ENT>40</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>180 min</ENT>
                        <ENT>1</ENT>
                        <ENT>80</ENT>
                        <ENT>30</ENT>
                        <ENT>90</ENT>
                        <ENT>
                            <SU>1</SU>
                             40
                        </ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>240 min</ENT>
                        <ENT>1</ENT>
                        <ENT>100</ENT>
                        <ENT>30</ENT>
                        <ENT>110</ENT>
                        <ENT>30</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>300 min</ENT>
                        <ENT>1</ENT>
                        <ENT>110</ENT>
                        <ENT>30</ENT>
                        <ENT>130</ENT>
                        <ENT>60</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>360 min</ENT>
                        <ENT>1</ENT>
                        <ENT>120</ENT>
                        <ENT>30</ENT>
                        <ENT>150</ENT>
                        <ENT>70</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>420 min</ENT>
                        <ENT>1</ENT>
                        <ENT>140</ENT>
                        <ENT>30</ENT>
                        <ENT>160</ENT>
                        <ENT>80</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT O="xl"/>
                        <ENT>480 min</ENT>
                        <ENT>1</ENT>
                        <ENT>150</ENT>
                        <ENT>30</ENT>
                        <ENT>180</ENT>
                        <ENT>80</ENT>
                        <ENT>30</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         The shutdown zone is equivalent to the Level A harassment distance.
                    </TNOTE>
                    <TNOTE>
                        <SU>2</SU>
                         The shutdown is smaller than the Level A harassment distance.
                    </TNOTE>
                </GPOTABLE>
                <P>
                    • DOT&amp;PF anticipates that the maximum number of piles to be installed and or the daily duration of pile driving or DTH use may vary significantly, with large differences in maximum zone sizes possible 
                    <PRTPAGE P="1078"/>
                    depending on the work planned for a given day (Table 7). Given this uncertainty, DOT&amp;PF will utilize a tiered system to identify and monitor the appropriate Level A harassment zones and shutdown zones on a daily basis, based on the maximum expected number of piles to be installed (impact or vibratory pile driving) or the maximum expected DTH duration for each day. At the start of each work day, DOT&amp;PF will determine the maximum scenario for that day (according to the defined duration intervals in Tables 7 and 9), which will determine the appropriate Level A harassment isopleth and associated shutdown zone for that day. This Level A harassment zone (Table 7) and associated shutdown zone (Table 9) must be observed by PSO(s) for the entire work day, regardless of whether DOT&amp;&amp;PF ultimately meets the anticipated scenario parameters for that day;
                </P>
                <P>• Marine mammals observed anywhere within visual range of the PSO will be tracked relative to construction activities. If a marine mammal is observed entering or within the shutdown zones indicated in Table 9, pile driving or DTH activities must be delayed or halted. If pile driving or DTH activities are delayed or halted due to the presence of a marine mammal, the activity may not commence or resume until either the animal has voluntarily exited and been visually confirmed beyond the shutdown zone (Table 9) or 15 minutes have passed without re-detection of the animal;</P>
                <P>
                    • Monitoring must take place from 30 minutes prior to initiation of pile driving (
                    <E T="03">i.e.,</E>
                     pre-clearance monitoring) through 30 minutes post-completion of pile driving or DTH activity;
                </P>
                <P>• Pre-start clearance monitoring must be conducted during periods of visibility sufficient for the lead PSO to determine that the shutdown zones indicated in Table 9 are clear of marine mammals. Pile driving may commence following 30 minutes of observation when the determination is made that the shutdown zones are clear of marine mammals;</P>
                <P>• The DOT&amp;PF must use soft start techniques when impact pile driving. Soft start requires contractors to provide an initial set of three strikes at reduced energy, followed by a 30-second waiting period, then two subsequent reduced energy strike sets. A soft start must be implemented at the start of each day's impact pile driving and at any time following cessation of impact pile driving for a period of 30 minutes or longer. Soft starts will not be used for vibratory pile installation and removal or for DTH activities. PSOs shall begin observing for marine mammals 30 minutes before “soft start” or in-water pile installation or removal begins; and</P>
                <P>• Pile driving activity must be halted upon observation of either a species for which incidental take is not authorized or a species for which incidental take has been authorized but the authorized number of takes has been met, entering or within the harassment zone.</P>
                <P>Based on our evaluation of the applicant's mitigation measures, as well as other measures considered by NMFS, NMFS has determined that the mitigation measures provide the means of effecting the least practicable impact on the affected species or stocks and their habitat, paying particular attention to rookeries, mating grounds, areas of similar significance, and on the availability of such species or stock for subsistence uses.</P>
                <HD SOURCE="HD1">Monitoring and Reporting</HD>
                <P>In order to issue an IHA for an activity, section 101(a)(5)(D) of the MMPA states that NMFS must set forth requirements pertaining to the monitoring and reporting of such taking. The MMPA implementing regulations at 50 CFR 216.104(a)(13) indicate that requests for authorizations must include the suggested means of accomplishing the necessary monitoring and reporting that will result in increased knowledge of the species and of the level of taking or impacts on populations of marine mammals that are expected to be present while conducting the activities. Effective reporting is critical both to compliance as well as ensuring that the most value is obtained from the required monitoring.</P>
                <P>Monitoring and reporting requirements prescribed by NMFS should contribute to improved understanding of one or more of the following:</P>
                <P>
                    • Occurrence of marine mammal species or stocks in the area in which take is anticipated (
                    <E T="03">e.g.,</E>
                     presence, abundance, distribution, density);
                </P>
                <P>
                    • Nature, scope, or context of likely marine mammal exposure to potential stressors/impacts (individual or cumulative, acute or chronic), through better understanding of: (1) action or environment (
                    <E T="03">e.g.,</E>
                     source characterization, propagation, ambient noise); (2) affected species (
                    <E T="03">e.g.,</E>
                     life history, dive patterns); (3) co-occurrence of marine mammal species with the activity; or (4) biological or behavioral context of exposure (
                    <E T="03">e.g.,</E>
                     age, calving or feeding areas);
                </P>
                <P>• Individual marine mammal responses (behavioral or physiological) to acoustic stressors (acute, chronic, or cumulative), other stressors, or cumulative impacts from multiple stressors;</P>
                <P>• How anticipated responses to stressors impact either: (1) long-term fitness and survival of individual marine mammals; or (2) populations, species, or stocks;</P>
                <P>
                    • Effects on marine mammal habitat (
                    <E T="03">e.g.,</E>
                     marine mammal prey species, acoustic habitat, or other important physical components of marine mammal habitat); and
                </P>
                <P>• Mitigation and monitoring effectiveness.</P>
                <HD SOURCE="HD2">Visual Monitoring</HD>
                <P>Monitoring must be conducted by qualified, NMFS-approved PSOs, in accordance with the following:</P>
                <P>
                    • PSOs must be independent of the activity contractor (
                    <E T="03">e.g.,</E>
                     employed by a subcontractor) and have no other assigned tasks during monitoring periods. At least one PSO must have prior experience performing the duties of a PSO during construction activity pursuant to a NMFS-issued IHA or Letter of Concurrence. Other PSOs may substitute other relevant experience, education (degree in biological science or related field), or training for prior experience performing the duties of a. PSOs must be approved by NMFS prior to beginning any activity subject to these IHAs;
                </P>
                <P>• DOT&amp;PF must employ at least two PSOs during all pile driving and DTH activities. A minimum of one PSO must be assigned to the active pile driving or DTH location to monitor for marine mammals and implement shutdown/delay procedures when applicable by calling for the shutdown to the hammer operator. At least one additional PSO is also required, and should be placed at the best practical vantage point(s) to ensure that the shutdown zones are fully monitored and as much as the Level B harassment zones are monitored as practicable; though the observation points may vary depending on the construction activity and location of the piles;</P>
                <P>• Where a team of three or more PSOs is required, a lead observer or monitoring coordinator must be designated. The lead observer must have prior experience performing the duties of a PSO during construction activity pursuant to a NMFS-issued incidental take authorization;</P>
                <P>• PSOs will use a hand-held GPS device, rangefinder, or reticle binoculars to verify the required monitoring distance from the project site; and</P>
                <P>
                    • PSOs must record all observations of marine mammals, regardless of distance from the pile being driven. PSOs shall document any behavioral 
                    <PRTPAGE P="1079"/>
                    reactions in concert with distance from piles being driven or removed.
                </P>
                <P>PSOs must have the following additional qualifications:</P>
                <P>• Ability to conduct field observations and collect data according to assigned protocols;</P>
                <P>• Experience or training in the field identification of marine mammals, including the identification of behaviors;</P>
                <P>• Sufficient training, orientation, or experience with the construction operation to provide for personal safety during observations;</P>
                <P>• Writing skills sufficient to record required information including but not limited to the number and species of marine mammals observed; dates and times when in-water construction activities were conducted; dates, times, and reason for implementation of mitigation (or why mitigation was not implemented when required); and marine mammal behavior; and</P>
                <P>• Ability to communicate orally, by radio or in person, with project personnel to provide real-time information on marine mammals observed in the area as necessary.</P>
                <HD SOURCE="HD2">Reporting</HD>
                <P>A draft marine mammal monitoring report will be submitted to NMFS within 90 days after the completion of pile driving and DTH activities, or 60 days prior to a requested date of issuance of any future IHAs for projects at the same location, whichever comes first. The reports will include an overall description of work completed, a narrative regarding marine mammal sightings, and associated PSO data sheets. Specifically, the reports must include:</P>
                <P>• Dates and times (begin and end) of all marine mammal monitoring;</P>
                <P>
                    • Construction activities occurring during each daily observation period, including the number and type of piles driven or removed and by what method (
                    <E T="03">i.e.,</E>
                     impact, vibratory, or DTH) and the total equipment duration for vibratory installation, removal and DTH for each pile or total number of strikes for each pile (impact driving);
                </P>
                <P>• PSO locations during marine mammal monitoring;</P>
                <P>• Environmental conditions during monitoring periods (at beginning and end of PSO shift and whenever conditions change significantly), including Beaufort sea state and any other relevant weather conditions including cloud cover, fog, sun glare, and overall visibility to the horizon, and estimated observable distance;</P>
                <P>
                    • Upon observation of a marine mammal, the following information: name of PSO who sighted the animal(s) and PSO location and activity at time of sighting; time of sighting; identification of the animal(s) (
                    <E T="03">e.g.,</E>
                     genus/species, lowest possible taxonomic level, or unidentified), PSO confidence in identification, and the composition of the group if there is a mix of species; distance and bearing of each marine mammal observed relative to the pile being driven for each sighting (if pile driving was occurring at time of sighting); estimated number of animals (minimum, maximum, and best estimate); estimated number of animals by cohort (adults, juveniles, neonates, group composition, sex class, 
                    <E T="03">etc.</E>
                    ); animal's closest point of approach and estimated time spent within the harassment zone; description of any marine mammal behavioral observations (
                    <E T="03">e.g.,</E>
                     observed behaviors such as feeding or traveling), including an assessment of behavioral responses thought to have resulted from the activity (
                    <E T="03">e.g.,</E>
                     no response or changes in behavioral state such as ceasing feeding, changing direction, flushing, or breaching);
                </P>
                <P>• Number of marine mammals detected within the harassment zones and shutdown zones, by species; and</P>
                <P>
                    • Detailed information about any implementation of any mitigation triggered (
                    <E T="03">e.g.,</E>
                     shutdowns and delays), a description of specific actions that ensued, and resulting changes in behavior of the animal(s), if any.
                </P>
                <P>If no comments are received from NMFS within 30 days, the draft final reports will constitute the final reports. If comments are received, a final report addressing NMFS comments must be submitted within 30 days after receipt of comments.</P>
                <HD SOURCE="HD2">Reporting Injured or Dead Marine Mammals</HD>
                <P>
                    In the event that personnel involved in the construction activities discover an injured or dead marine mammal, the IHA-holder must immediately cease the specified activities and report the incident to the Office of Protected Resources, NMFS (
                    <E T="03">PR.ITP.MonitoringReports@noaa.gov</E>
                    ), and to the Alaska Regional Stranding Coordinator as soon as feasible. If the death or injury was clearly caused by the specified activity, the DOT&amp;PF must immediately cease the specified activities until NMFS is able to review the circumstances of the incident and determine what, if any, additional measures are appropriate to ensure compliance with the terms of the IHAs. The DOT&amp;PF must not resume their activities until notified by NMFS. The report must include the following information:
                </P>
                <P>• Time, date, and location (latitude and longitude) of the first discovery (and updated location information if known and applicable);</P>
                <P>• Species identification (if known) or description of the animal(s) involved;</P>
                <P>• Condition of the animal(s) (including carcass condition if the animal is dead);</P>
                <P>• Observed behaviors of the animal(s), if alive;  </P>
                <P>• If available, photographs or video footage of the animal(s); and</P>
                <P>• General circumstances under which the animal was discovered.</P>
                <HD SOURCE="HD1">Negligible Impact Analysis and Determination</HD>
                <P>
                    NMFS has defined negligible impact as an impact resulting from the specified activity that cannot be reasonably expected to, and is not reasonably likely to, adversely affect the species or stock through effects on annual rates of recruitment or survival (50 CFR 216.103). A negligible impact finding is based on the lack of likely adverse effects on annual rates of recruitment or survival (
                    <E T="03">i.e.,</E>
                     population-level effects). An estimate of the number of takes alone is not enough information on which to base an impact determination. In addition to considering estimates of the number of marine mammals that might be “taken” through harassment, NMFS considers other factors, such as the likely nature of any impacts or responses (
                    <E T="03">e.g.,</E>
                     intensity, duration), the context of any impacts or responses (
                    <E T="03">e.g.,</E>
                     critical reproductive time or location, foraging impacts affecting energetics), as well as effects on habitat, and the likely effectiveness of the mitigation. We also assess the number, intensity, and context of estimated takes by evaluating this information relative to population status. Consistent with the 1989 preamble for NMFS' implementing regulations (54 FR 40338, September 29, 1989), the impacts from other past and ongoing anthropogenic activities are incorporated into this analysis via their impacts on the baseline (
                    <E T="03">e.g.,</E>
                     as reflected in the regulatory status of the species, population size and growth rate where known, ongoing sources of human-caused mortality, or ambient noise levels).
                </P>
                <P>
                    To avoid repetition, the majority of our analysis applies to all the species listed in Table 2, given that many of the anticipated effects of the DOT&amp;PFs construction activities on different marine mammal stocks are expected to be relatively similar in nature. Where there are meaningful differences between species or stocks, or groups of species, in anticipated individual 
                    <PRTPAGE P="1080"/>
                    responses to activities, impact of expected take on the population due to differences in population status, or impacts on habitat, they are described independently in the analysis below.
                </P>
                <P>Pile driving and DTH activities associated with the project, as outlined previously, have the potential to disturb or displace marine mammals. Specifically, the specified activities may result in take, in the form of Level B harassment and, for some species Level A harassment, from underwater sounds generated by pile driving and DTH systems. Potential takes could occur if marine mammals are present in zones ensonified above the thresholds for Level B harassment or Level A harassment, identified above, while activities are underway.</P>
                <P>
                    The DOT&amp;PF's construction activities and associated impacts will occur within a limited, confined area of the stocks' range. The work will occur in the vicinity of the seaplane dock immediately adjacent to Hydaburg and sound from the construction activities will be blocked by Sukkwan Island, Spook Island, Mushroom Island, and the coastline along Prince of Wales Island both southeast and northwest of the project site (see Figure 1-2 in the DOT&amp;PF's application) to a maximum distance of 5,162 m and area of 4.34 km
                    <SU>2</SU>
                    . The intensity and duration of take by Level A harassment and Level B harassment will be minimized through use of mitigation measures described herein. Further the amount of take authorized is small when compared to stock abundance. In addition, NMFS does not anticipate that serious injury or mortality will occur as a result of the DOT&amp;PF's construction activities given the nature of the activity, even in the absence of required mitigation.
                </P>
                <P>
                    Exposures to elevated sound levels produced during pile driving and DTH may cause behavioral disturbance of some individuals. Behavioral responses of marine mammals to pile driving, pile removal, and DTH systems at the project site are expected to be mild, short term, and temporary. Effects on individuals that are taken by Level B harassment, as enumerated in the Estimated Take section, on the basis of reports in the literature as well as monitoring from other similar activities, will likely be limited to reactions such as increased swimming speeds, increased surfacing time, or decreased foraging (if such activity were occurring) (
                    <E T="03">e.g.,</E>
                     Thorson and Reyff, 2006). Marine mammals within the Level B harassment zones may not show any visual cues they are disturbed by activities or they could become alert, avoid the area, leave the area, or display other mild responses that are not observable such as changes in vocalization patterns or increased haul out time (Thorson and Reyff, 2006). Additionally, some of the species present in the region will only be present temporarily based on seasonal patterns or during transit between other habitats. These temporarily present species will be exposed to even smaller periods of noise-generating activity, further decreasing the impacts. Most likely, individual animals will simply move away from the sound source and be temporarily displaced from the area, although even this reaction has been observed primarily only in association with impact pile driving. Because DOT&amp;PF's activities could occur during any season, takes may occur during important feeding times. The project area though represents a small portion of available foraging habitat and impacts on marine mammal feeding for all species should be minimal.
                </P>
                <P>
                    The activities analyzed here are similar to numerous other construction activities conducted along southeastern Alaska (
                    <E T="03">e.g.,</E>
                     86 FR 43190, August 6, 2021; 87 FR 15387, March 18, 2022), which have taken place with no known long-term adverse consequences from behavioral harassment. These reactions and behavioral changes are expected to subside quickly when the exposures cease and, therefore, no such long-term adverse consequences should be expected (
                    <E T="03">e.g.,</E>
                     Graham 
                    <E T="03">et al.,</E>
                     2017). The intensity of Level B harassment events will be minimized through use of mitigation measures described herein, which were not quantitatively factored into the take estimates. The DOT&amp;PF will use at least two PSOs stationed strategically to increase detectability of marine mammals during in-water pile driving and DTH activities, enabling a high rate of success in implementation of shutdowns to avoid or minimize injury for most species. Further, given the absence of any major rookeries and haulouts within the estimated harassment zones, we assume that potential takes by Level B harassment will have an inconsequential short-term effect on individuals and will not result in population-level impacts.
                </P>
                <P>As stated in the mitigation section, DOT&amp;PF will implement shutdown zones that equal or exceed many of the Level A harassment isopleths shown in Table 9. Take by Level A harassment is authorized for some species (harbor seals, northern elephant seals, harbor porpoises, Dall's porpoises, humpback whales, and minke whales) to account for the potential that an animal could enter and remain within the Level A harassment zone for a duration long enough to incur PTS. Any take by Level A harassment is expected to arise from, at most, a small degree of PTS because animals will need to be exposed to higher levels and/or longer duration than are expected to occur here in order to incur any more than a small degree of PTS.</P>
                <P>
                    Due to the levels and durations of likely exposure, animals that experience PTS will likely only receive slight PTS, 
                    <E T="03">i.e.,</E>
                     minor degradation of hearing capabilities within regions of hearing that align most completely with the frequency range of the energy produced by DOT&amp;PF's in-water construction activities (
                    <E T="03">i.e.,</E>
                     the low-frequency region below 2 kHz), not severe hearing impairment or impairment in the reigns of greatest hearing sensitivity. If hearing impairment does occur, it is most likely that the affected animal will lose a few dBs in its hearing sensitivity, which in most cases is not likely to meaningfully affect its ability to forage and communicate with conspecifics. There are no data to suggest that a single instance in which an animal accrues PTS (or TTS) and is subject to behavioral disturbance will result in impacts to reproduction or survival. If PTS were to occur, it will be at a lower level likely to accrue to a relatively small portion of the population by being a stationary activity in one particular location. Additionally, and as noted previously, some subset of the individuals that are behaviorally harassed could also simultaneously incur some small degree of TTS for a short duration of time. Because of the small degree anticipated, though, any PTS or TTS potentially incurred here is not expected to adversely impact individual fitness, let alone annual rates of recruitment or survival.
                </P>
                <P>Theoretically, repeated, sequential exposure to pile driving noise over a long duration could result in more severe impacts to individuals that could affect a population. However, the limited number of non-consecutive pile driving days for this project and the absence of any pinniped haulouts or other known cetacean residency patterns in the action area means that these types of impacts are not anticipated.</P>
                <P>
                    For all species except humpback whales, there are no known BIAs near the project zone that will be impacted by DOT&amp;PF's planned activities. For humpback whales, the whole of southeast Alaska is a seasonal feeding BIA from May through September (Wild 
                    <E T="03">et al.,</E>
                     2023), however, Sukkwan Strait is a small passageway and represents a very small portion of the total available habitat. Also, while southeast Alaska is considered an important area for feeding 
                    <PRTPAGE P="1081"/>
                    humpback during this time, it is not currently designated as critical habitat for humpback whales (86 FR 21082, April 21, 2021).
                </P>
                <P>The project is also not expected to have significant adverse effects on any marine mammal habitat. The project activities will not modify existing marine mammal habitat since the project will occur within the same footprint as existing marine infrastructure. Impacts to the immediate substrate are anticipated, but these will be limited to minor, temporary suspension of sediments, which could impact water quality and visibility for a short amount of time but which will not be expected to have any effects on individual marine mammals.  </P>
                <P>In addition, impacts to marine mammal prey species are expected to be minor and temporary and to have, at most, short-term effects on foraging of individual marine mammals, and likely no effect on the populations of marine mammals as a whole. Overall, the area impacted by the project is very small compared to the available surrounding habitat, and does not include habitat of particular importance. The most likely impact to prey will be temporary behavioral avoidance of the immediate area. During construction activities, it is expected that some fish and marine mammals will temporarily leave the area of disturbance, thus impacting marine mammals' foraging opportunities in a limited portion of the foraging range. But, because of the relatively small area of the habitat that may be affected, and lack of any habitat of particular importance, the impacts to marine mammal habitat are not expected to cause significant or long-term negative consequences.</P>
                <P>In summary and as described above, the following factors primarily support our determination that the impacts resulting from this activity are not expected to adversely affect any of the species or stocks through effects on annual rates of recruitment or survival:</P>
                <P>• No serious injury or mortality is anticipated or authorized;</P>
                <P>• Level A harassment authorized is expected to be of a lower degree that will not impact the fitness of any animals;</P>
                <P>• Anticipated incidents of Level B harassment consist of, at worst, temporary modifications in behavior;</P>
                <P>
                    • The required mitigation measures (
                    <E T="03">i.e.,</E>
                     soft starts, shutdown zones) are expected to be effective in reducing the effects of the specified activity by minimizing the numbers of marine mammals exposed to injurious levels of sound, and by ensuring that any take by Level A harassment is, at most, a small degree of PTS;
                </P>
                <P>• The intensity of anticipated takes by Level B harassment is low for all stocks and will not be of a duration or intensity expected to result in impacts on reproduction or survival;</P>
                <P>• Minimal impacts to marine mammal habitat/prey are expected;</P>
                <P>• The only known area of specific biological importance covers a broad area of southeast Alaska for humpback whales, and the project area is a very small portion of that BIA. No other known areas of particular biological importance to any of the affected species or stocks are impacted by the activity, including ESA-designated critical habitat;</P>
                <P>• The project area represents a very small portion of the available foraging area for all potentially impacted marine mammal species and stocks and anticipated habitat impacts are minor; and</P>
                <P>• Monitoring reports from similar work in southeast Alaska have documented little to no effect on individuals of the same species impacted by the specified activities.</P>
                <P>Based on the analysis contained herein of the likely effects of the specified activity on marine mammals and their habitat, and taking into consideration the implementation of the monitoring and mitigation measures, NMFS finds that the total marine mammal take from the activity will have a negligible impact on all affected marine mammal species or stocks.</P>
                <HD SOURCE="HD1">Small Numbers</HD>
                <P>As noted previously, only small numbers of incidental take may be authorized under section 101(a)(5)(A) and (D) of the MMPA for specified activities other than military readiness activities. The MMPA does not define small numbers and so, in practice, where estimated numbers are available, NMFS compares the number of individuals taken to the most appropriate estimation of abundance of the relevant species or stock in our determination of whether an authorization is limited to small numbers of marine mammals. When the predicted number of individuals to be taken is fewer than one-third of the species or stock abundance, the take is considered to be of small numbers. Additionally, other qualitative factors may be considered in the analysis, such as the temporal or spatial scale of the activities.</P>
                <P>The maximum annual amount of take NMFS proposes to authorize for five marine mammal stocks is below one-third of the estimated stock abundance for all species (in fact, take of individuals is less than six percent of the abundance of all affected stocks, see Table 8). The number of animals authorized to be taken from these stocks will be considered small relative to the relevant stock's abundances even if each estimated take occurred to a new individual. Some individuals may return multiple times in a day, but PSOs will count them as separate individuals if they cannot be individually identified.</P>
                <P>
                    The Alaska stock of Dall's porpoise has no official NMFS abundance estimate for this area, as the most recent estimate is greater than eight years old. Abundance estimates for Dall's porpoise in inland waters of southeast Alaska were calculated from 19 line-transect vessel surveys from 1991 to 2012 (Jefferson 
                    <E T="03">et al.,</E>
                     2019). Abundance across the whole period was estimated at 5,381 (CV = 0.25), 2,680 (CV = 0.20), and 1,637 (CV = 0.23) in the spring, summer, and fall, respectively (Jefferson 
                    <E T="03">et al.,</E>
                     2019). The minimum population estimate (N
                    <E T="52">MIN</E>
                    ) for the entire Alaska stock is assumed to correspond to the point estimate of a 2015 vessel-based abundance computed by Rone 
                    <E T="03">et al.</E>
                     (2017) in the Gulf of Alaska (N = 13,110; CV = 0.22) (Muto 
                    <E T="03">et al.,</E>
                     2022); however, the study area of this survey corresponds to a small fraction of the range of the stock and, thus it is reasonable to assume that the stock size is equal to or greater than that estimate (Muto 
                    <E T="03">et al.,</E>
                     2022). Therefore, the 22 takes of this stock authorized clearly represent small numbers of this stock.  
                </P>
                <P>
                    The abundance estimate for the Mexico-North Pacific stock of humpback whales is also considered to be unknown as estimates are based on data collected more than 15 years ago (Young 
                    <E T="03">et al.,</E>
                     2023). A multi-strata mark-recapture analysis of data from 2004 through 2006 resulted in an abundance estimate of 5,890 (CV = 0.075) humpbacks for Southeast Alaska and northern British Columbia (Wade 2021); however, this estimate represents a mixture of whales from up to three winter areas (the western North Pacific (Asia), Hawaii, and Mexico), and thus does not represent the abundance of just the Mexico-North Pacific stock in its summer areas. The number of animals in the feeding areas belonging to the Mexico-North Pacific stock was determined by multiplying the abundance estimate for each feeding area (
                    <E T="03">i.e.,</E>
                     Bering Sea and Aleutian Islands, Gulf of Alaska, and Southeast Alaska and northern British Columbia) by the probability of movement between that feeding area and the Mexican wintering area, as estimated by Wade 
                    <PRTPAGE P="1082"/>
                    (2021), and then adding those estimates together. This resulted in an estimate of 918 animals (CV = 0.217) and an N
                    <E T="52">MIN</E>
                     estimate of 766 animals for this stock (Young 
                    <E T="03">et al.,</E>
                     2023). While the abundance trend for this stock is unclear; the 32 takes authorized represent small numbers of this stock based on this available data.
                </P>
                <P>
                    There is also no current or historical estimate of the Alaska minke whale stock, but minke whale abundance has been estimated to be over 1,000 whales in portions of Alaska (Muto 
                    <E T="03">et al.,</E>
                     2022) so the 3 takes authorized represent small numbers of this stock. Additionally, the range of the Alaska stock of minke whales is extensive, stretching from the Canadian Pacific coast to the Chukchi Sea, and DOT&amp;PF's project area impacts a small portion of this range. Therefore, the three takes of minke whale authorized is small relative to estimated survey abundance, even if each authorized take occurred to a new individual.
                </P>
                <P>Based on the analysis contained herein of the construction activity (including the mitigation and monitoring measures) and the anticipated take of marine mammals, NMFS finds that small numbers of marine mammals will be taken relative to the population size of the affected species or stocks.</P>
                <HD SOURCE="HD1">Unmitigable Adverse Impact Analysis and Determination</HD>
                <P>In order to issue an IHA, NMFS must find that the specified activity will not have an “unmitigable adverse impact” on the subsistence uses of the affected marine mammal species or stocks by Alaskan Natives. NMFS has defined “unmitigable adverse impact” in 50 CFR 216.103 as an impact resulting from the specified activity: (1) that is likely to reduce the availability of the species to a level insufficient for a harvest to meet subsistence needs by: (i) causing the marine mammals to abandon or avoid hunting areas; (ii) directly displacing subsistence users; or (iii) placing physical barriers between the marine mammals and the subsistence hunters; and (2) that cannot be sufficiently mitigated by other measures to increase the availability of marine mammals to allow subsistence needs to be met.</P>
                <P>Alaska Natives have traditionally harvested subsistence resources in southeast Alaska for many hundreds of years, particularly large terrestrial mammals, marine mammals, salmon, and other fish (Alaska Department of Fish and Game (ADF&amp;G), 1997). Harbor seals and sea otters are reported to be the marine mammal species most regularly harvested for subsistence in the waters surrounding Hydaburg (NOAA, 2013). An estimated 14.4 harbor seals were harvested by Hydaburg residents every year from 2000 through 2008 (ADF&amp;G, 2009a, 2009b). Hunting usually occurs in the late fall and winter (ADF&amp;G, 2009a). The ADF&amp;G has not recorded harvest of cetaceans from Hydaburg (ADF&amp;G, 2022). There are no subsistence activities near the project that target humpback whales, and subsistence hunters rarely target Steller sea lions near the project area.</P>
                <P>Approximately 93 percent of Hydaburg residents identified as Alaska Native (Sill and Koster, 2017) in 2012. Nearly half of all households harvested wild resources in 2012, with nearly all Hydaburg households using salmon, non-salmon fish, marine invertebrates, and vegetation (Sill and Koster, 2017). Only six percent of Hydaburg households participated in the hunting, use, or receiving of harbor seals in 2012, whereas up to eight percent used sea otters (Sill and Koster, 2017). Based on data from 2012, marine mammals account for approximately one percent (1,666 pounds or 756 kg) of all subsistence harvest in Hydaburg (Sill and Koster, 2017).</P>
                <P>All pile driving and DTH activities will take place in the vicinity of seaplane dock immediately adjacent to Hydaburg where subsistence activities do not generally occur. The project will not have an adverse impact on the availability of marine mammals for subsistence use at locations farther away. Some minor, short-term disturbance of the harbor seals or sea otters could occur, but this is not likely to have any measurable effect on subsistence harvest activities in the region. No changes to availability of subsistence resources will result from the specified activities. Additionally, DOT&amp;PF is working with Haida Elders on the project to raise awareness and collaborate on the project within the local community.</P>
                <P>Based on the description of the specified activity, the measures described to minimize adverse effects on the availability of marine mammals for subsistence purposes, and the mitigation and monitoring measures, NMFS has determined that there will not be an unmitigable adverse impact on subsistence uses from the DOT&amp;PF's construction activities.</P>
                <HD SOURCE="HD1">Endangered Species Act</HD>
                <P>
                    Section 7(a)(2) of the ESA (16 U.S.C. 1531 
                    <E T="03">et seq.</E>
                    ) requires that each Federal agency insure that any action it authorizes, funds, or carries out is not likely to jeopardize the continued existence of any endangered or threatened species or result in the destruction or adverse modification of designated critical habitat. To ensure ESA compliance for the issuance of IHAs, NMFS consults internally whenever we propose to authorize take for endangered or threatened species, in this case with NMFS' Alaska Regional Office (AKRO).
                </P>
                <P>There is one marine mammal species (Mexico DPS humpback whales) with confirmed occurrence in the project area that is listed as threatened under the ESA. AKRO issued a Biological Opinion on December 19, 2023 under section 7 of the ESA, on the issuance of an IHA to the DOT&amp;PF under section 101(a)(5)(D) of the MMPA by the NMFS Office of Protected Resources. The Biological Opinion concluded that the proposed action is not likely to jeopardize the continued existence of Mexico DPS humpback whales.</P>
                <HD SOURCE="HD1">National Environmental Policy Act</HD>
                <P>
                    To comply with the National Environmental Policy Act of 1969 (NEPA; 42 U.S.C. 4321 
                    <E T="03">et seq.</E>
                    ) and NOAA Administrative Order (NAO) 216-6A, NMFS must review our action (
                    <E T="03">i.e.,</E>
                     the issuance of an IHA) with respect to potential impacts on the human environment.
                </P>
                <P>This action is consistent with categories of activities identified in Categorical Exclusion B4 (IHAs with no anticipated serious injury or mortality) of the Companion Manual for NAO 216-6A, which do not individually or cumulatively have the potential for significant impacts on the quality of the human environment and for which we have not identified any extraordinary circumstances that will preclude this categorical exclusion. Accordingly, NMFS has determined that the issuance of the IHA qualifies to be categorically excluded from further NEPA review.</P>
                <HD SOURCE="HD1">Authorization</HD>
                <P>NMFS has issued an IHA to the DOT&amp;PF for the potential harassment of small numbers of nine marine mammal species incidental to the Hydaburg Seaplane Base Refurbishment Project in Hydaburg, Alaska, that includes the previously explained mitigation, monitoring and reporting requirements. </P>
                <SIG>
                    <P>Dated: January 3, 2024.</P>
                    <NAME>Kimberly Damon-Randall,</NAME>
                    <TITLE>Director, Office of Protected Resources, National Marine Fisheries Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00189 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-22-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="1083"/>
                <AGENCY TYPE="N">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Department of the Air Force</SUBAGY>
                <DEPDOC>[Docket ID: USAF-2024-HQ-0002]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of the Air Force, Department of Defense (DoD).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>60-Day information collection notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        In compliance with the 
                        <E T="03">Paperwork Reduction Act of 1995,</E>
                         the Department of the Air Force announces a proposed public information collection and seeks public comment on the provisions thereof. Comments are invited on: whether the proposed collection of information is necessary for the proper performance of the functions of the agency, including whether the information shall have practical utility; the accuracy of the agency's estimate of the burden of the proposed information collection; ways to enhance the quality, utility, and clarity of the information to be collected; and ways to minimize the burden of the information collection on respondents, including through the use of automated collection techniques or other forms of information technology.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Consideration will be given to all comments received by March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments, identified by docket number and title, 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">Mail:</E>
                         Department of Defense, Office of the Assistant to the Secretary of Defense for Privacy, Civil Liberties, and Transparency, Regulatory Directorate, 4800 Mark Center Drive, Mailbox #24, Suite 08D09, Alexandria, VA 22350-1700.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions received must include the agency name, docket number and title for this 
                        <E T="04">Federal Register</E>
                         document. The general policy for comments and other submissions from members of the public is to make these submissions available for public viewing on the internet at 
                        <E T="03">http://www.regulations.gov</E>
                         as they are received without change, including any personal identifiers or contact information.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>To request more information on this proposed information collection or to obtain a copy of the proposal and associated collection instruments, please write to AF Information Collections Office, 1800 Air Force Pentagon, Suite 4C146, Washington, DC 20330, ATTN: Ms. Mia Day, or call 703-697-4593.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Title; Associated Form; and OMB Number:</E>
                     Student Information Management System (SIMS); OMB Control Number: 0701-SIMS.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     The information is required to enroll and track students in flight training courses. Contact information is necessary to ensure students can be informed of last-minute changes in their schedules and emergency contact info is necessary in the event of a training accident. Employment, Position/Rank, flight physical, and security clearance information, among other types of information, is necessary to ensure students meet the prerequisites for their training.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or households (foreign military personnel).
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     45.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     45.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     45.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     1 hour.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     On occasion.
                </P>
                <SIG>
                    <DATED>Dated: January 3, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00254 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6001-FR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Office of the Secretary</SUBAGY>
                <DEPDOC>[Docket ID: DoD-2023-HA-0104]</DEPDOC>
                <SUBJECT>Submission for OMB Review; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Assistant Secretary of Defense for Health Affairs (OASD(HA)), Department of Defense (DoD).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>30-Day information collection notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The DoD has submitted to the Office of Management and Budget (OMB) for clearance the following proposal for collection of information under the provisions of the Paperwork Reduction Act.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Consideration will be given to all comments received by February 8, 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 by selecting “Currently under 30-day Review—Open for Public Comments” or by using the search function.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Angela Duncan, (571) 344-1358, 
                        <E T="03">whs.mc-alex.esd.mbx.dd-dod-information-collections@mail.mil.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    <E T="03">Title; Associated Form; and OMB Number:</E>
                     Restructure or Realignment of Military Medical Treatment Facilities; OMB Control Number: 0720-RMTF.
                </P>
                <P>
                    <E T="03">Type of Request:</E>
                     New.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     53,100.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     2.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     106,200.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     10 minutes.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     17,700.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     The National Defense Authorization Act (NDAA) for Fiscal Year (FY) 2017 (NDAA FY 2017—Pub. L. 114-328), section 703 “Military Medical Treatment Facilities” (MTFs) states that, there shall be an update on the study (
                    <E T="03">i.e.,</E>
                     a report) from the 2015 Military Health System Modernization Study that addresses the realignment or restructuring of MTFs. As part of the report on the implementation plan to restructure or realign all MTFs, this survey will provide valuable data on TRICARE beneficiary's experience with the transition from receiving their care at an MTF to now receiving care in the private-sector with a network provider/facility. The collection of this information will be from TRICARE prime enrollees empaneled at MTFs undergoing MTF restructuring as a result of NDAA FY 2017, section 703. The survey will be given two times, the first iteration given two weeks after transition to collect immediate information regarding the transition and access to care experience; a second survey will be released six months after transition to review progress. These TRICARE prime enrollees will be responding to questions relating to how their transition from the MTF to either a Network (private-sector care), Primary Care Manager (PCM), or TRICARE select resulted. This information will assist the DHA with assessing this restructuring effort as well as future efforts to ensure beneficiaries receive high-quality care. Specifically, survey findings will show what problems beneficiaries faced during the transition from their MTF PCM to a network PCM, details on access to care now with a network PCM, satisfaction with their new network PCM, and communications about the transition overall.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or households.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     On occasion.
                    <PRTPAGE P="1084"/>
                </P>
                <P>
                    <E T="03">Respondent's Obligation:</E>
                     Voluntary.
                </P>
                <P>
                    <E T="03">OMB Desk Officer:</E>
                     Mr. Matt Eliseo.
                </P>
                <P>You may also submit comments and recommendations, identified by Docket ID number and title, by the following method:</P>
                <P>
                    • 
                    <E T="03">Federal eRulemaking Portal: http://www.regulations.gov.</E>
                     Follow the instructions for submitting comments.
                </P>
                <P>
                    <E T="03">Instructions:</E>
                     All submissions received must include the agency name, Docket ID number, and title for this 
                    <E T="04">Federal Register</E>
                     document. The general policy for comments and other submissions from members of the public is to make these submissions available for public viewing on the internet at 
                    <E T="03">http://www.regulations.gov</E>
                     as they are received without change, including any personal identifiers or contact information.
                </P>
                <P>
                    <E T="03">DOD Clearance Officer:</E>
                     Ms. Angela Duncan.
                </P>
                <P>
                    Requests for copies of the information collection proposal should be sent to Ms. Duncan at 
                    <E T="03">whs.mc-alex.esd.mbx.dd-dod-information-collections@mail.mil.</E>
                </P>
                <SIG>
                    <DATED>Dated: January 3, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00173 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6001-FR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Office of the Secretary</SUBAGY>
                <DEPDOC>[Docket ID: DoD-2024-HA-0004]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Assistant Secretary of Defense for Health Affairs (OASD(HA)), Department of Defense (DoD).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>60-Day information collection notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        In compliance with the 
                        <E T="03">Paperwork Reduction Act of 1995,</E>
                         the Defense Health Agency announces a proposed public information collection and seeks public comment on the provisions thereof. Comments are invited on: whether the proposed collection of information is necessary for the proper performance of the functions of the agency, including whether the information shall have practical utility; the accuracy of the agency's estimate of the burden of the proposed information collection; ways to enhance the quality, utility, and clarity of the information to be collected; and ways to minimize the burden of the information collection on respondents, including through the use of automated collection techniques or other forms of information technology.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Consideration will be given to all comments received by March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments, identified by docket number and title, 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">Mail:</E>
                         Department of Defense, Office of the Assistant to the Secretary of Defense for Privacy, Civil Liberties, and Transparency, Regulatory Directorate, 4800 Mark Center Drive, Mailbox #24, Suite 08D09, Alexandria, VA 22350-1700.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions received must include the agency name, docket number and title for this 
                        <E T="04">Federal Register</E>
                         document. The general policy for comments and other submissions from members of the public is to make these submissions available for public viewing on the internet at 
                        <E T="03">http://www.regulations.gov</E>
                         as they are received without change, including any personal identifiers or contact information.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>To request more information on this proposed information collection or to obtain a copy of the proposal and associated collection instruments, please write to Defense Health Agency, 7700 Arlington Blvd., Falls Church, VA 22042, Amanda Grifka, 703-681-1771.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Title; Associated Form; and OMB Number:</E>
                     Women's Reproductive Health Care Provider Survey (WRHCPS); OMB Control Number: 0720-WRHS.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     Health care provider knowledge, beliefs, and practices may have an impact on active-duty service women's (ADSW) access to contraception and overall reproductive health. The proposed survey is devised to be a sufficiently large and representative sample of the diverse professionals who provide reproductive and contraceptive care to ADSW at health care visits (
                    <E T="03">e.g.,</E>
                     readiness visits, pre-deployment, and during deployment). The survey will be designed to capture provider self-reported beliefs, clinical knowledge on reproductive health care (including contraceptive counseling) and prescription of contraception care for and during deployment. Data and analysis from the survey will enable DoD to evaluate, enhance, and where needed, improve reproductive services delivery and educational interventions; provide a strong basis for planning policy and services related to ADSW's reproductive and contraceptive health; and provide data, programs, and details necessary for replication and peer review. In addition, the proposed one-time survey meets a Congressional mandate and serves as an appropriate follow-up to the WRHS by determining whether identified gaps in contraceptive access are the result of provider knowledge and attitudes. The 116-48 SASC Report for FY2020 required DoD to conduct a survey to better understand provider knowledge and beliefs related to provision of contraceptives to ADSW. The target population of the survey includes uniformed (active component only) and civilian MHS personnel.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Federal Government employees.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     709.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     2,128.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     2,128.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     20 minutes.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     Once.
                </P>
                <SIG>
                    <DATED>Dated: January 3, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00261 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6001-FR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Office of the Secretary</SUBAGY>
                <DEPDOC>[Docket ID: DoD-2023-HA-0080]</DEPDOC>
                <SUBJECT>Submission for OMB Review; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Assistant Secretary of Defense for Health Affairs (OASD(HA)), Department of Defense (DoD).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>30-Day information collection notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The DoD has submitted to the Office of Management and Budget (OMB) for clearance the following proposal for collection of information under the provisions of the Paperwork Reduction Act.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Consideration will be given to all comments received by February 8, 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 by selecting “Currently under 30-day Review—Open for Public Comments” or by using the search function.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Angela Duncan, (571) 344-1358, 
                        <PRTPAGE P="1085"/>
                        <E T="03">whs.mc-alex.esd.mbx.dd-dod-information-collections@mail.mil.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Title; Associated Form; and OMB Number:</E>
                     Personnel Accountability and Assessment for a Public Health Emergency; DD Form 3112; OMB Control Number: 0720-0067.
                </P>
                <P>
                    <E T="03">Type of Request:</E>
                     Extension.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     100,000.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     100,000.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     5 minutes.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     8,333.3 hours.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     The principal purpose of the DD Form 3112, “Personnel Accountability and Assessment Notification for a Public Health Emergency,” is to collect information used to protect the health and safety of individuals working in, residing on, or assigned to DoD installations, facilities, field operations, and commands, and to protect the DoD mission. When authorized by DoD, this form may be used to provide information about individuals who are infected or otherwise impacted by a public health emergency or similar occurrence or when there is an isolated incident in which an individual learns they have been exposed to a contagious disease or hazardous substance/agent. The form will also be used to document personnel accountability for and status of DoD-affiliated personnel in a natural or man-made disaster, or when directed by the Secretary of Defense. Such events could include severe weather events, acts of terrorism or severe destruction. The collection of this information is necessary to support the DoD in protecting the health and safety of DoD-affiliated individuals and maintain the DoD mission.
                </P>
                <P>The information collected will inform decisions made about the status of DoD facilities and spaces that Affected Individuals have entered. This information may be used to make decisions to protect the health and safety of DoD personnel and facilities. It may also be used to notify other individuals who may have contacted the Affected Individual to make informed decisions about the status of the DoD facility and office space that subject individuals exposed to communicable diseases or hazardous substances/agents have entered. This information may be used to make Health Protection Condition (HPCON) level decisions. It may also be used to notify other individuals who may have been in contact with the subject individual(s).</P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or households.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     On occasion.
                </P>
                <P>
                    <E T="03">Respondent's Obligation:</E>
                     Voluntary.
                </P>
                <P>
                    <E T="03">OMB Desk Officer:</E>
                     Mr. Matt Eliseo.
                </P>
                <P>You may also submit comments and recommendations, identified by Docket ID number and title, by the following method:</P>
                <P>
                    • 
                    <E T="03">Federal eRulemaking Portal: http://www.regulations.gov.</E>
                     Follow the instructions for submitting comments.
                </P>
                <P>
                    <E T="03">Instructions:</E>
                     All submissions received must include the agency name, Docket ID number, and title for this 
                    <E T="04">Federal Register</E>
                     document. The general policy for comments and other submissions from members of the public is to make these submissions available for public viewing on the internet at 
                    <E T="03">http://www.regulations.gov</E>
                     as they are received without change, including any personal identifiers or contact information.
                </P>
                <P>
                    <E T="03">DOD Clearance Officer:</E>
                     Ms. Angela Duncan.
                </P>
                <P>
                    Requests for copies of the information collection proposal should be sent to Ms. Duncan at 
                    <E T="03">whs.mc-alex.esd.mbx.dd-dod-information-collections@mail.mil.</E>
                </P>
                <SIG>
                    <DATED>Dated: January 3, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00174 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6001-FR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Office of the Secretary</SUBAGY>
                <DEPDOC>[Docket ID: DoD-2024-OS-0003]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Under Secretary of Defense for Personnel and Readiness (OUSD(P&amp;R)), Department of Defense (DoD).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>60-Day information collection notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        In compliance with the 
                        <E T="03">Paperwork Reduction Act of 1995,</E>
                         the OUSD(P&amp;R) announces a proposed public information collection and seeks public comment on the provisions thereof. Comments are invited on: whether the proposed collection of information is necessary for the proper performance of the functions of the agency, including whether the information shall have practical utility; the accuracy of the agency's estimate of the burden of the proposed information collection; ways to enhance the quality, utility, and clarity of the information to be collected; and ways to minimize the burden of the information collection on respondents, including through the use of automated collection techniques or other forms of information technology.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Consideration will be given to all comments received by March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments, identified by docket number and title, 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">Mail:</E>
                         Department of Defense, Office of the Assistant to the Secretary of Defense for Privacy, Civil Liberties, and Transparency, Regulatory Directorate, 4800 Mark Center Drive, Mailbox #24, Suite 08D09, Alexandria, VA 22350-1700.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions received must include the agency name, docket number and title for this 
                        <E T="04">Federal Register</E>
                         document. The general policy for comments and other submissions from members of the public is to make these submissions available for public viewing on the internet at 
                        <E T="03">http://www.regulations.gov</E>
                         as they are received without change, including any personal identifiers or contact information.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        To request more information on this proposed information collection or to obtain a copy of the proposal and associated collection instruments, please write to Study of Adolescent (SOAR) Team, 140 Sylvester Road, San Diego, CA 92106, Dr. Hope McMaster, (800) 643-1817, 
                        <E T="03">USN.DOD.SOARinfo@health.mil.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Title; Associated Form; and OMB Number:</E>
                     Military Experiences, Risk and Protective Factors, and Adolescent Health and Well-Being Survey; OMB Control Number: 0704-0635.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     This study is designed to assess the direct and indirect association of military experiences with adolescents' psychosocial adjustment and physical health, academic achievement, and educational and career aspirations to identify risk and protective factors that may promote or inhibit positive outcomes among military-connected adolescents and their families.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or households.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     1,888.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     3,776.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     3,776.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     30 minutes.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     On occasion.
                </P>
                <P>Military-connected adolescents surveyed every 18-24 months until age 25.</P>
                <SIG>
                    <PRTPAGE P="1086"/>
                    <DATED>Dated: January 3, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00256 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6001-FR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF EDUCATION</AGENCY>
                <DEPDOC>[Docket No.: ED-2024-SCC-0003]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities; Comment Request; Migrant Student Information Exchange User Application Form</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Elementary and Secondary Education (OESE), Department of Education (ED).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Paperwork Reduction Act (PRA) of 1995, the Department is proposing an extension without change of a currently approved information collection request (ICR).</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>
                        To access and review all the documents related to the information collection listed in this notice, please use 
                        <E T="03">http://www.regulations.gov</E>
                         by searching the Docket ID number ED-2024-SCC-0003. Comments submitted in response to this notice should be submitted electronically through the Federal eRulemaking Portal at 
                        <E T="03">http://www.regulations.gov</E>
                         by selecting the Docket ID number or via postal mail, commercial delivery, or hand delivery. If the 
                        <E T="03">regulations.gov</E>
                         site is not available to the public for any reason, the Department will temporarily accept comments at 
                        <E T="03">ICDocketMgr@ed.gov.</E>
                         Please include the docket ID number and the title of the information collection request when requesting documents or submitting comments. Please note that comments submitted after the comment period will not be accepted. Written requests for information or comments submitted by postal mail or delivery should be addressed to the Manager of the Strategic Collections and Clearance Governance and Strategy Division, U.S. Department of Education, 400 Maryland Ave. SW, LBJ, Room 6W203, Washington, DC 20202-8240.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>For specific questions related to collection activities, please contact Benjamin Starr, 202-245-8116.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Department, in accordance with the Paperwork Reduction Act of 1995 (PRA) (44 U.S.C. 3506(c)(2)(A)), provides the general public and Federal agencies with an opportunity to comment on proposed, revised, and continuing collections of information. This helps the Department assess the impact of its information collection requirements and minimize the public's reporting burden. It also helps the public understand the Department's information collection requirements and provide the requested data in the desired format. The Department is soliciting comments on the proposed information collection request (ICR) that is described below. The Department is especially interested in public comment addressing the following issues: (1) is this collection necessary to the proper functions of the Department; (2) will this information be processed and used in a timely manner; (3) is the estimate of burden accurate; (4) how might the Department enhance the quality, utility, and clarity of the information to be collected; and (5) how might the Department minimize the burden of this collection on the respondents, including through the use of information technology. Please note that written comments received in response to this notice will be considered public records.</P>
                <P>
                    <E T="03">Title of Collection:</E>
                     Migrant Student Information Exchange User Application Form.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     1810-0686.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     An extension without change of a currently approved ICR.
                </P>
                <P>
                    <E T="03">Respondents/Affected Public:</E>
                     State, local, and Tribal governments.
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Responses:</E>
                     732.
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Burden Hours:</E>
                     366.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     Regulations for the Migrant Information Exchange (MSIX), effective on June 9, 2016, were issued by the U.S. Department of Education (the Department). The MSIX, a nationwide, electronic records exchange mechanism mandated under Title I, Part C of the Elementary and Secondary Education Act (ESEA), as amended. As a condition of receiving a grant of funds under the Migrant Education Program (MEP), each State educational agency (SEA) is required to collect, maintain, and submit minimum health and education-related data to MSIX within established timeframes. MSIX is designed to facilitate timely school enrollment, grade and course placement, accrual of secondary course credits and participation in the MEP for migratory children. Additionally, the regulations help the Department to determine accurate migratory child counts and meet other MEP reporting requirements. The MEP is authorized under sections 1301-1309 in title I, part C of the ESEA, as amended. MSIX and the minimum data elements (MDEs) are authorized specifically under section 1308(b) of the ESEA, as amended.
                </P>
                <P>The Department is requesting approval to extend the 1810-0686 information collection that supports statutory requirements for data collection under title I, part C—MEP. The purpose of the MSIX User Application Form is to collect user directory data to verify the identity of users in order to grant access to the MSIX system for the purpose of transferring migratory student data. The application collects information on an MSIX users' identity, title/position, work address, work telephone, email, and role in MSIX.</P>
                <SIG>
                    <DATED>Dated: January 4, 2024.</DATED>
                    <NAME>Kun Mullan,</NAME>
                    <TITLE>PRA Coordinator, Strategic Collections and Clearance, Governance and Strategy Division, Office of Chief Data Officer, Office of Planning, Evaluation and Policy Development.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00255 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4000-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF ENERGY</AGENCY>
                <SUBJECT>National Definition for a Zero Emissions Building: Part 1 Operating Emissions Version 1.00, Draft Criteria</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Energy Efficiency and Renewable Energy, Department of Energy.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Request for information (RFI).</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The White House Office of Domestic Climate Policy (Climate Policy Office) seeks to create a standardized, verifiable basis for defining a zero emissions building. The U.S. Department of Energy (DOE) is issuing this RFI to receive input on Part 1 of the draft National Definition for a Zero Emissions Building. DOE intends to publish Part 1 of the definition in early 2024.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>DOE will accept comments, data, and information regarding this request for information no later than 5 p.m. (ET) on February 5, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Responses to this RFI must be submitted electronically at 
                        <E T="03">https://forms.office.com/g/Y0Ss3UFdL3.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Hayes Jones, U.S. Department of Energy, Office of Energy Efficiency and Renewable Energy (EERE), Building Technologies Office, Commercial Buildings Integration, (202) 586-8873, 
                        <E T="03">Hayes.Jones@ee.doe.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">
                    SUPPLEMENTARY INFORMATION:
                    <PRTPAGE P="1087"/>
                </HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    President Biden called for net-zero emissions, economy-wide, by 2050 and a 100% clean energy electricity sector by 2035.
                    <SU>1</SU>
                    <FTREF/>
                     The building sector currently contributes more than one-third of U.S. greenhouse gases. Within the building sector, the Biden-Harris Administration has set the goal to make zero emissions resilient new construction and retrofits common practice by 2030. Accomplishing these goals will require increasing efficiency and expanding clean energy capacity. Zero emissions buildings will plug into a grid that is rapidly becoming cleaner. All buildings, both new and existing, have a critical role to play in achieving a clean energy economy. A clean energy economy advances the goals of tackling the climate crisis, and protecting public health and the environment, including local communities' health and well-being. Executive Order 14096, “Revitalizing Our Nation's Commitment to Environmental Justice for All,” directs every Federal agency to advance environmental justice for all, including work to better protect communities with environmental justice concerns from the increasing impacts of climate change. It is also vital that the Administration is implementing Executive Order 14096 and the historic Justice40 Initiative, which set the goal that 40 percent of the overall benefits of certain Federal investments in climate and other key areas flow to disadvantaged communities.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">www.whitehouse.gov/climate/.</E>
                    </P>
                </FTNT>
                <P>
                    A broadly accepted common minimum definition for a zero emissions building, as well as a pathway for verification, is foundational to efforts by public and private entities to transition the building sector to zero emissions.
                    <SU>2</SU>
                    <FTREF/>
                     The intent of Part 1 of the National Definition for a Zero Emissions Building is to create a standardized, consistent, measurable basis for zero operating emissions buildings. This clear market signal and consistent target is intended to help move the building sector to zero emissions. The definition may serve as a framework that users can achieve through multiple pathways to influence the design and operation of buildings to substantially reduce building sector emissions.
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">www.whitehouse.gov/climate/and www.energy.gov/sites/default/files/2023-03/doe-fy-2024-budget-vol-4-eere-v2.pdf.</E>
                    </P>
                </FTNT>
                <P>The minimum criteria included to define a zero operating emissions building is a building that is:</P>
                <P>• Highly energy efficient,</P>
                <P>• Free of on-site emissions from energy use, and</P>
                <P>• Powered solely from clean energy.</P>
                <P>Part 1 of the draft National Definition for a Zero Emissions Building focuses on operational emissions which have well-established measurement protocols. Reducing the whole life cycle emissions of a building also requires minimizing the embodied carbon of the building, as well as minimizing the impacts of refrigerants. Such emissions are not within scope for Part 1 and may be considered in subsequent parts to the National Definition for a Zero Emission Building.</P>
                <P>This definition can be applied to existing buildings and new construction of non-federally owned buildings. This definition is not intended for federally owned buildings, which are governed as a portfolio through statutory and executive guidance.</P>
                <P>
                    Part 1 of the draft definition in full, which includes details on the criteria above, is available here: 
                    <E T="03">https://www.energy.gov/eere/buildings/national-definition-zero-emissions-building.</E>
                     This RFI is intended to collect broader technical input on Part 1 of the draft definition. DOE will consider responses to this RFI before finalizing version 1.00 of Part 1 of the National Definition for a Zero Emissions Building.
                </P>
                <P>
                    DOE issued a RFI in 2015 for zero energy buildings.
                    <SU>3</SU>
                    <FTREF/>
                     While the 2015 RFI was informative, the National Definition for a Zero Emissions Building in this RFI has different parameters.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         RFI for Definition for Zero Energy, Buildings 80 FR 499 (Jan. 6, 2015).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Purpose</HD>
                <P>The purpose of this RFI is to solicit feedback from industry, academia, research laboratories, government agencies, and other stakeholders on Part 1 of a draft National Definition for a Zero Emissions Building.</P>
                <HD SOURCE="HD1">Disclaimer and Important Notes</HD>
                <P>This RFI is not a Funding Opportunity Announcement (FOA); therefore, EERE is not accepting applications at this time. EERE may issue a FOA in the future based on or related to the content and responses to this RFI; however, EERE may also elect not to issue a FOA. There is no guarantee that a FOA will be issued as a result of this RFI. Responding to this RFI does not provide any advantage or disadvantage to potential applicants if EERE chooses to issue a FOA regarding the subject matter. Final details, including the anticipated award size, quantity, and timing of EERE funded awards, will be subject to Congressional appropriations and direction. Any information obtained as a result of this RFI is intended to be used by the Government on a non-attribution basis for planning and strategy development; this RFI does not constitute a formal solicitation for proposals or abstracts. Your response to this notice will be treated as information only. EERE will review and consider all responses in its formulation of program strategies for the identified materials of interest that are the subject of this request. EERE will not provide reimbursement for costs incurred in responding to this RFI. Respondents are advised that EERE is under no obligation to acknowledge receipt of the information received or provide feedback to respondents with respect to any information submitted under this RFI. Responses to this RFI do not bind EERE to any further actions related to this topic.</P>
                <HD SOURCE="HD1">Confidential Business Information</HD>
                <P>Pursuant to 10 CFR 1004.11, any person submitting information that he or she believes to be confidential and exempt by law from public disclosure should submit via email, postal mail, or hand delivery two well-marked copies: one copy of the document marked “confidential” including all the information believed to be confidential, and one copy of the document marked “non-confidential” with the information believed to be confidential deleted. Submit these documents via email or on a CD, if feasible. DOE will make its own determination about the confidential status of the information and treat it according to its determination.</P>
                <HD SOURCE="HD1">Evaluation and Administration by Federal and Non-Federal Personnel</HD>
                <P>Federal employees are subject to the non-disclosure requirements of a criminal statute, the Trade Secrets Act, 18 U.S.C. 1905. The Government may seek the advice of qualified non-Federal personnel. The Government may also use non-Federal personnel to conduct routine, nondiscretionary administrative activities. The respondents, by submitting their response, consent to EERE providing their response to non-Federal parties. Non-Federal parties given access to responses must be subject to an appropriate obligation of confidentiality prior to being given access. Submissions may be reviewed by support contractors and private consultants.</P>
                <HD SOURCE="HD1">Request for Information Questions</HD>
                <P>
                    Please reference the linked full draft of Part 1 of the National Definition for a Zero Emissions Building when responding to these questions.
                    <PRTPAGE P="1088"/>
                </P>
                <P>A. Are the draft criteria clear and appropriate for the definition for a zero emissions building? Should any other criteria be considered for Part 1? Please provide specific feedback about this draft definition.</P>
                <P>B. Energy efficiency criteria.</P>
                <P>○ Should energy efficiency be considered a criteria for the definition of a zero emissions building?</P>
                <P>○ If the efficiency of an existing building should be considered, do you agree that requiring energy performance in the top 25% of similar buildings is an appropriate measure of energy efficiency for this definition? (ENERGY STAR® score of 75 or above.) Should it be higher or lower?</P>
                <P> Are there other benchmarks or approaches that should be considered?</P>
                <P> For an existing building, is one year of measured energy performance an appropriate requirement for demonstrating efficiency or is another approach appropriate?</P>
                <P> Are the draft criteria appropriate for single-family homes? Are there other benchmarks that should be considered for single-family homes?</P>
                <P>
                    ○ For new construction, are the draft criteria appropriate? The modeled building performance is at least 10% lower than the energy use according to the latest version of IECC or ASHRAE 90.1 (
                    <E T="03">e.g.,</E>
                     model energy code) and the building is designed to achieve an ENERGY STAR score of at least 90 (for eligible buildings). Are there other benchmarks that should be considered?
                </P>
                <P> Are the draft criteria appropriate for single family homes? Are there other benchmarks that should be considered for single family homes?</P>
                <P>C. On-site emissions from energy use.</P>
                <P>• Should there be an exemption allowed for emission producing emergency generation? Are any other exemptions needed?</P>
                <P>• Should biofuels consumed on-site be allowed? If so, how?</P>
                <P>D. Clean energy generation and procurement.</P>
                <P>• Are the clean energy criteria provided appropriate for this definition? Are there other clean energy criteria that should be considered? Should community solar qualify for this requirement? If so, how?</P>
                <P>
                    • Should there be a proximity requirement for off-site power used to meet the clean power criterion? If so, how should a proximity requirement be implemented (
                    <E T="03">e.g.,</E>
                     regional definition, phase-in, etc.)?
                </P>
                <P>E. Documentation is important for effective implementation.</P>
                <P>• Should organizations leveraging the definition be able to determine whether buildings have to meet it annually, one time, or on a different frequency?</P>
                <P>• If the definition is extended to single-family homes, what documentation should be required?</P>
                <P>• Are licensed professional and third-party certification bodies the appropriate parties to independently verify the documentation that a building has met the definition? Beyond existing government resources such as EPA's ENERGY STAR Portfolio Manager, are there other methods to verify meeting the zero emissions building definition?  </P>
                <P>
                    • What time frame should be used for greenhouse gas (GHG) calculations (
                    <E T="03">i.e.</E>
                     hourly, monthly by year, annually)? Explain how this would be implemented effectively across the market.
                </P>
                <P>• What other verification criteria are necessary to make this definition useful for the marketplace?</P>
                <P>• Are there any issues regarding conflict or synergy with regional, state or local energy and climate programs that ought to be addressed?</P>
                <P>F. Use cases.</P>
                <P>• Is it important for a national definition to cover all building types, including commercial, multifamily, and single-family?</P>
                <P>• Are there any other recommendations that would help clarify and improve the definition?</P>
                <P>• While Part 1 of the definition focuses on operating emissions, what other areas should be considered in future parts of the definition, such as embodied carbon, refrigerant, and grid interactivity?</P>
                <HD SOURCE="HD1">Request for Information Response Guidelines</HD>
                <P>
                    Responses to this RFI must be submitted electronically at 
                    <E T="03">https://forms.office.com/g/Y0Ss3UFdL3.</E>
                     Only responses to this web form will be accepted.
                </P>
                <P>Respondents may answer as many or as few questions as they wish.</P>
                <P>EERE will not respond to individual submissions or publish publicly a compendium of responses. A response to this RFI will not be viewed as a binding commitment to develop or pursue the project or ideas discussed.</P>
                <P>Respondents are requested to provide the following information at the start of their response to this RFI:</P>
                <P>• Company/institution name;</P>
                <P>• Company/institution contact;</P>
                <P>• Contact's address, phone number, and email address.</P>
                <P>
                    Virtual Listening Sessions may be held additional information will be posted at: 
                    <E T="03">https://www.energy.gov/eere/buildings/national-definition-zero-emissions-building.</E>
                </P>
                <HD SOURCE="HD1">Signing Authority</HD>
                <P>
                    This document of the Department of Energy was signed on December 28, 2023, by Jeffrey Marootian, Principal Deputy Assistant Secretary for Energy Efficiency and Renewable Energy, pursuant to delegated authority from the Secretary of Energy. That document with the original signature and date is maintained by DOE. For administrative purposes only, and in compliance with requirements of the Office of the Federal Register, the undersigned DOE Federal Register Liaison Officer has been authorized to sign and submit the document in electronic format for publication, as an official document of the Department of Energy. This administrative process in no way alters the legal effect of this document upon publication in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <SIG>
                    <DATED>Signed in Washington, DC, on January 4, 2024.</DATED>
                    <NAME>Treena V. Garrett,</NAME>
                    <TITLE>Federal Register Liaison Officer, U.S. Department of Energy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00203 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6450-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF ENERGY</AGENCY>
                <SUBAGY>Federal Energy Regulatory Commission</SUBAGY>
                <DEPDOC>[Docket No. CP24-34-000]</DEPDOC>
                <SUBJECT>Transwestern Pipeline Company, LLC; Notice of Request Under Blanket Authorization and Establishing Intervention and Protest Deadline</SUBJECT>
                <P>Take notice that on December 27, 2023, Transwestern Pipeline Company, LLC (Transwestern), 1300 Main Street, Houston, Texas 77002, filed in the above referenced docket, a prior notice request pursuant to sections 157.205 and 157.216 of the Commission's regulations under the Natural Gas Act (NGA), and Transwestern's blanket certificate issued in Docket No. CP82-534-000, for authorization to abandon in place the Crawford Compressor Station consisting of two natural gas compressor turbines, compressors, yard and station piping, and ancillary related facilities located in Eddy County, New Mexico, (Crawford CS or Project). The proposed abandonment will eliminate the need to maintain facilities that are not necessary for transportation of natural gas on Transwestern's system, all as more fully set forth in the request, which is on file with the Commission, and open to public inspection.</P>
                <P>
                    In addition to publishing the full text of this document in the 
                    <E T="04">Federal Register</E>
                    , the Commission provides all 
                    <PRTPAGE P="1089"/>
                    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">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. Public access to records formerly available in the Commission's physical Public Reference Room, which was located at the Commission's headquarters, 888 First Street NE, Washington, DC 20426, are now available via the Commission's website. For assistance, contact the Federal Energy Regulatory Commission at 
                    <E T="03">FercOnlineSupport@ferc.gov</E>
                     or call toll-free, (886) 208-3676 or TTY (202) 502-8659.
                </P>
                <P>
                    Any questions concerning this request should be directed to Blair Lichtenwalter, 1300 Main Street, Houston TX 77002, (713) 989-2605, or by email at 
                    <E T="03">Blair.Lichtenwalter@energytransfer.com.</E>
                </P>
                <HD SOURCE="HD1">Public Participation</HD>
                <P>There are three ways to become involved in the Commission's review of this project: you can file a protest to the project, you can file a motion to intervene in the proceeding, and you can file comments on the project. There is no fee or cost for filing protests, motions to intervene, or comments. The deadline for filing protests, motions to intervene, and comments is 5:00 p.m. Eastern Time on March 4, 2024. How to file protests, motions to intervene, and comments is explained below.</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>
                <HD SOURCE="HD2">Protests  </HD>
                <P>
                    Pursuant to section 157.205 of the Commission's regulations under the NGA,
                    <SU>1</SU>
                    <FTREF/>
                     any person 
                    <SU>2</SU>
                    <FTREF/>
                     or the Commission's staff may file a protest to the request. If no protest is filed within the time allowed or if a protest is filed and then withdrawn within 30 days after the allowed time for filing a protest, the proposed activity shall be deemed to be authorized effective the day after the time allowed for protest. If a protest is filed and not withdrawn within 30 days after the time allowed for filing a protest, the instant request for authorization will be considered by the Commission.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         18 CFR 157.205.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         Persons include individuals, organizations, businesses, municipalities, and other entities. 18 CFR 385.102(d).
                    </P>
                </FTNT>
                <P>
                    Protests must comply with the requirements specified in section 157.205(e) of the Commission's regulations,
                    <SU>3</SU>
                    <FTREF/>
                     and must be submitted by the protest deadline, which is March 4, 2024. A protest may also serve as a motion to intervene so long as the protestor states it also seeks to be an intervenor.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         18 CFR 157.205(e).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">Interventions</HD>
                <P>Any person has the option to file a motion to intervene in this proceeding. Only intervenors have the right to request rehearing of Commission orders issued in this proceeding and to subsequently challenge the Commission's orders in the U.S. Circuit Courts of Appeal.</P>
                <P>
                    To intervene, you must submit a motion to intervene to the Commission in accordance with Rule 214 of the Commission's Rules of Practice and Procedure 
                    <SU>4</SU>
                    <FTREF/>
                     and the regulations under the NGA 
                    <SU>5</SU>
                    <FTREF/>
                     by the intervention deadline for the project, which is March 4, 2024. As described further in Rule 214, your motion to intervene must state, to the extent known, your position regarding the proceeding, as well as your interest in the proceeding. For an individual, this could include your status as a landowner, ratepayer, resident of an impacted community, or recreationist. You do not need to have property directly impacted by the project in order to intervene. For more information about motions to intervene, refer to the FERC website at 
                    <E T="03">https://www.ferc.gov/resources/guides/how-to/intervene.asp.</E>
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         18 CFR 385.214.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         18 CFR 157.10.
                    </P>
                </FTNT>
                <P>All timely, unopposed motions to intervene are automatically granted by operation of Rule 214(c)(1). Motions to intervene that are filed after the intervention deadline are untimely and may be denied. Any late-filed motion to intervene must show good cause for being late and must explain why the time limitation should be waived and provide justification by reference to factors set forth in Rule 214(d) of the Commission's Rules and Regulations. A person obtaining party status will be placed on the service list maintained by the Secretary of the Commission and will receive copies (paper or electronic) of all documents filed by the applicant and by all other parties.</P>
                <HD SOURCE="HD2">Comments</HD>
                <P>Any person wishing to comment on the project may do so. The Commission considers all comments received about the project in determining the appropriate action to be taken. To ensure that your comments are timely and properly recorded, please submit your comments on or before March 4, 2024. The filing of a comment alone will not serve to make the filer a party to the proceeding. To become a party, you must intervene in the proceeding.</P>
                <HD SOURCE="HD2">How To File Protests, Interventions, and Comments</HD>
                <P>There are two ways to submit protests, motions to intervene, and comments. In both instances, please reference the Project docket number CP24-34-000 in your submission.</P>
                <P>
                    (1) You may file your protest, motion to intervene, and comments by using the Commission's eFiling feature, which is located on the Commission's website (
                    <E T="03">www.ferc.gov</E>
                    ) under the link to Documents and Filings. New eFiling users must first create an account by clicking on “eRegister.” You will be asked to select the type of filing you are making; first select “General” and then select “Protest”, “Intervention”, or “Comment on a Filing”; or 
                    <SU>6</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         Additionally, you may file your comments electronically by using the eComment feature, which is located on the Commission's website at 
                        <E T="03">www.ferc.gov</E>
                         under the link to Documents and Filings. Using eComment is an easy method for interested persons to submit brief, text-only comments on a project.
                    </P>
                </FTNT>
                <P>(2) You can file a paper copy of your submission by mailing it to the address below. Your submission must reference the Project docket number CP24-34-000.</P>
                <P>
                    <E T="03">To file via USPS:</E>
                     Debbie-Anne Reese, Acting Secretary, Federal Energy Regulatory Commission, 888 First Street NE, Washington, DC 20426.
                </P>
                <P>
                    <E T="03">To file via any other method:</E>
                     Debbie-Anne Reese, Acting Secretary, Federal Energy Regulatory Commission, 12225 Wilkins Avenue, Rockville, Maryland 20852.
                </P>
                <P>
                    The Commission encourages electronic filing of submissions (option 1 above) and has eFiling staff available to assist you at (202) 502-8258 or 
                    <E T="03">FercOnlineSupport@ferc.gov.</E>
                </P>
                <P>
                    Protests and motions to intervene must be served on the applicant either by mail or email (with a link to the document) at: Blair Lichtenwalter, Senior Director, Regulatory Affairs, 1300 Main Street, Houston, TX 77002, or at 
                    <PRTPAGE P="1090"/>
                    <E T="03">Blair.Lichtenwalter@energytransfer.com.</E>
                     Any subsequent submissions by an intervenor must be served on the applicant and all other parties to the proceeding. Contact information for parties can be downloaded from the service list at the eService link on FERC Online.
                </P>
                <HD SOURCE="HD1">Tracking the Proceeding</HD>
                <P>
                    Throughout the proceeding, additional information about the project will be available from the Commission's Office of External Affairs, at (866) 208-FERC, or on the FERC website at 
                    <E T="03">www.ferc.gov</E>
                     using the “eLibrary” link as described above. 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>
                    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. For more information and to register, go to 
                    <E T="03">www.ferc.gov/docs-filing/esubscription.asp.</E>
                </P>
                <SIG>
                    <DATED>Dated: January 3, 2024.</DATED>
                    <NAME>Debbie-Anne Reese,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00223 Filed 1-8-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. CP22-511-001]</DEPDOC>
                <SUBJECT>Notice of Request for Extension of Time</SUBJECT>
                <P>Take notice that on December 28, 2023, Ozark Gas Transmission, LLC (Ozark) requested that the Federal Energy Regulatory Commission (Commission) grant an extension of time, until May 29, 2024, to complete construction and place into service the Ozark Supply Access Project (Project) located in Lawrence County, Arkansas. On September 28, 2022, the Commission issued a Notice of Request Under Blanket Authorization, which established a 60-day comment period, ending on November 28, 2022, to file protests. No protests were filed during the comment period, and accordingly the project was authorized on November 29, 2022 and by Rule should have been completed within one year.</P>
                <P>
                    In its 2023 Extension of Time Request, Ozark states that it was not able to complete all the work associated with the Project by the November 29, 2023, deadline. To date Ozark reported completion of the Standing Rock Compressor Station modifications 
                    <SU>1</SU>
                    <FTREF/>
                     and the Loop Line 
                    <SU>2</SU>
                    <FTREF/>
                     portions of the Project as well as progress at the Raney Compressor Station and MRT Meter Station portions of the Project.
                    <SU>3</SU>
                    <FTREF/>
                     There was no progress reported for the interconnection point with the Natural Gas Pipeline Company of America, LLC. Ozark attributes the delay to material procurement and delivery timelines still being behind schedule due to the COVID-19 pandemic. Additionally, Ozark states that obtaining approvals for final design and materials related to various elements of the new interconnection points from the other interstate pipelines has proved challenging. Finally, construction crews have experienced delays at times due to heavy rain leading to wet conditions. Accordingly, Ozark requests an extension of time until May 29, 2024, to complete construction of project facilities with in-service projected to occur at the beginning of May 2024.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         See Ozark's Weekly Status Report No. 22 (filed June 7, 2023) under Docket No. CP22-511-000, Accession No. 20230607-503-5039.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         See Ozark's Weekly Status Report No. 25 (filed June 28, 2023) under Docket No. CP22-511-000, Accession No. 20230628-5018.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         See Ozark's Weekly Status Report No. 51 (filed December 27, 2023) under Docket No. CP22-511-000, Accession No. 20231227-5034.
                    </P>
                </FTNT>
                <P>This notice establishes a 15-calendar day intervention and comment period deadline. Any person wishing to comment on Ozark's request for an extension of time may do so. No reply comments or answers will be considered. If you wish to obtain legal status by becoming a party to the proceedings for this request, you should, on or before the comment date stated below, file a motion to intervene in accordance with the requirements of the Commission's Rules of Practice and Procedure (18 CFR 385.214 or 385.211) and the Regulations under the Natural Gas Act (NGA) (18 CFR 157.10).</P>
                <P>
                    As a matter of practice, the Commission itself generally acts on requests for extensions of time to complete construction for NGA facilities when such requests are contested before order issuance. For those extension requests that are contested,
                    <SU>4</SU>
                    <FTREF/>
                     the Commission will aim to issue an order acting on the request within 45 days.
                    <SU>5</SU>
                    <FTREF/>
                     The Commission will address all arguments relating to whether the applicant has demonstrated there is good cause to grant the extension.
                    <SU>6</SU>
                    <FTREF/>
                     The Commission will not consider arguments that re-litigate the issuance of the certificate order, including whether the Commission properly found the project to be in the public convenience and necessity and whether the Commission's environmental analysis for the certificate complied with the National Environmental Policy Act (NEPA).
                    <SU>7</SU>
                    <FTREF/>
                     At the time a pipeline requests an extension of time, orders on certificates of public convenience and necessity are final and the Commission will not re-litigate their issuance.
                    <SU>8</SU>
                    <FTREF/>
                     The Director of the Office of Energy Projects, or his or her designee, will act on all of those extension requests that are uncontested.
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         Contested proceedings are those where an intervenor disputes any material issue of the filing. 18 CFR 385.2201(c)(1).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">Algonquin Gas Transmission, LLC,</E>
                         170 FERC ¶ 61,144, at P 40 (2020).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         
                        <E T="03">Id.</E>
                         at P 40.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         Similarly, the Commission will not re-litigate the issuance of an NGA section 3 authorization, including whether a proposed project is not inconsistent with the public interest and whether the Commission's environmental analysis for the permit order complied with NEPA.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         
                        <E T="03">Algonquin Gas Transmission, LLC,</E>
                         170 FERC ¶ 61,144, at P 40 (2020).
                    </P>
                </FTNT>
                <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. Public access to records formerly available in the Commission's physical Public Reference Room, which was located at the Commission's headquarters, 888 First Street NE, Washington, DC 20426, are now available via the Commission's website. 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>
                    The Commission strongly encourages electronic filings of comments in lieu of paper using the “eFile” link at 
                    <E T="03">http://www.ferc.gov.</E>
                     In lieu of electronic filing, you may submit a paper copy which must reference the Project docket number.
                </P>
                <P>
                    <E T="03">To file via USPS:</E>
                     Debbie-Anne Reese, Acting Secretary, Federal Energy Regulatory Commission, 888 First Street NE, Washington, DC 20426.
                </P>
                <P>
                    <E T="03">To file via any other courier:</E>
                     Debbie-Anne Reese, Acting Secretary, Federal Energy Regulatory Commission, 12225 Wilkins Avenue, Rockville, Maryland 20852.
                    <PRTPAGE P="1091"/>
                </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>
                    <E T="03">Comment Date:</E>
                     5 p.m. Eastern Time on January 18, 2024.
                </P>
                <SIG>
                    <DATED>Dated: January 3, 2024.</DATED>
                    <NAME>Debbie-Anne Reese,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00225 Filed 1-8-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 corporate filings:</P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     EC24-34-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Sentinel Energy Center, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Application for Authorization Under Section 203 of the Federal Power Act of Sentinel Energy Center, LLC.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     12/29/23.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20231229-5452.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 1/19/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     EC24-35-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Richland-Stryker Generation LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Application for Authorization Under Section 203 of the Federal Power Act of Richland-Stryker Generation LLC.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5473.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 1/23/24.
                </P>
                <P>Take notice that the Commission received the following Complaints and Compliance filings in EL Dockets:</P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     EL24-19-000; QF23-400-001; QF23-402-001; QF23-403-001; QF23-404-001; QF23-409-001; QF23-411-001; QF23-412-001; QF23-413-001; QF23-414-001; QF23-415-001; QF23-416-001; QF23-417-001; QF23-418-001; QF23-419-001; QF23-420-001; QF23-426-001; QF23-427-001; QF23-429-001; QF23-431-001; QF23-432-001; QF23-464-001; QF23-467-001; QF23-469-001; QF23-502-001; QF23-503-001; QF23-537-001; QF23-539-001; QF23-540-001; QF23-543-001; QF23-544-001; QF23-545-001; QF23-548-001; QF23-717-001; QF23-721-001; QF23-725-001; QF23-774-001; QF23-855-001; QF23-984-001.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Prologis Targeted U.S. Logistics Fund, L.P., Sequoia Solar 2, LLC, ESNJ-PLD-EDISON5, LLC, ESCA-PLD-TRACY6, LLC, ESNJ-PLD-WOODBRIDGE4, LLC, ESNJ-PLD-JAMESBURG1, LLC, ESNJ-PLD-SOUTHBRUNSWICK5, LLC, ESNJ-PLD-SOUTHBRUNSWICK7, LLC, ESNJ-PLD-SOUTHBRUNSWICK2, LLC, ESCA-PLD-ANAHEIM1, LLC, ESNJ-PLD-CRANBURY1, LLC, ESNJ-PLD-CRANBURY2, LLC, ESCA-PLD-TRACY5, LLC, ESNJ-PLD-EDISON1, LLC, Sequoia Solar 3 LLC, ESNJ-PLD-WOODBRIDGE1, LLC, Sequoia Solar 1 LLC, ESNJ-PLD-EASTBRUNSWICK1, LLC, ESNJ-PLD-SOUTHBRUNSWICK8, LLC, ESCA-PLD-RIALTO1, LLC, ODT Solar LLC, ESNJ-PLD-WOODBRIDGE2, LLC, ESNJ-PLD-CARTERET8, LLC, ESCA-PLD-TRACY3, LLC, ESCA-PLD-TRACY1, LLC, ESCA-PLD-TRACY10, LLC, ESCA-PLD-TRACY2, LLC, ESNJ-PLD-SOUTHBRUNSWICK1, LLC, ESNJ-PLD-EDISON9, LLC, ESNJ-PLD-EDISON2, LLC, ESNJ-PLD-EDISON3, LLC, ESNJ-PLD-EDISON6, LLC, ESNJ-PLD-EDISON5, LLC, ESNY-PLD-JFKC, LLC, ESNY-PLD-JFKD, LLC, ESNY-PLD-JFKCB, LLC, ESNY-PLD-JFKCA, LLC, ESNJ-PLD-ELIZABETH1, LLC, Prologis Inc.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Petition for Declaratory Order of Prologis Inc., et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     11/16/23.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20231116-5196.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/2/24.
                </P>
                <P>Take notice that the Commission received the following electric rate filings:</P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-1427-008; ER18-1343-017; ER19-529-014; ER19-1074-014; ER19-1075-014; ER19-1819-007; ER19-1820-007; ER19-1821-007; ER19-2728-005; ER19-2729-005; ER21-2426-003; ER22-1010-006.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     TerraForm IWG Acquisition Holdings II, LLC, CPRE 1 Lessee, LLC, Lily Solar Lessee, LLC, Lily Solar LLC, Speedway Solar NC, LLC, Stony Knoll Solar, LLC, Broad River Solar, LLC, Brookfield Renewable Energy Marketing US LLC, Brookfield Energy Marketing Inc., Brookfield Renewable Trading and Marketing LP, Carolina Solar Power, LLC, Brookfield Energy Marketing LP.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Triennial Market Power Analysis and Notice of Change of Status for Southeast Region of Brookfield Energy Marketing LP, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5475.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 3/4/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-1484-032; ER12-2381-018; ER13-1069-021; ER14-1140-008.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Inspire Energy Holdings, LLC, MP2 Energy LLC, MP2 Energy NE LLC, Shell Energy North America (US), L.P.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Triennial Market Power Analysis and Change in Status for Southeast Region of Shell Energy North America (US), L.P., et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5479.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 3/4/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-1946-019; ER10-2201-007; ER13-291-006; ER14-2140-016; ER14-2141-016; ER20-57-006; ER20-58-006; ER20-339-006; ER20-422-006.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     FL Solar 1, LLC, Twiggs County Solar, LLC, FL Solar 4, LLC, GA Solar 3, LLC, Selmer Farm, LLC, Mulberry Farm, LLC, EnergyMark, LLC, Marina Energy, LLC, Broad River Energy LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Triennial Market Power Analysis for Southeast Region of Broad River Energy LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5478.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 3/4/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-2063-005.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Otter Tail Power Company.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Triennial Market Power Analysis for Central Region of Otter Tail Power Company.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     12/29/23.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20231229-5450.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/27/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-2984-064.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Merrill Lynch Commodities, Inc.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Triennial Market Power Analysis for Central Region of Merrill Lynch Commodities, Inc.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     12/29/23.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20231229-5451.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/27/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-3100-015; ER10-3107-015.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Walton County Power, LLC, MPC Generating, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Triennial Market Power Analysis for Southeast Region of MPC Generating, LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5472.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 3/4/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-3125-016.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     AL Sandersville, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Triennial Market Power Analysis for Southeast Region of AL Sandersville, LLC.
                    <PRTPAGE P="1092"/>
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5469.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 3/4/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER13-2490-013; ER17-311-009; ER17-1742-009; ER19-53-005; ER19-2595-008; ER19-2670-008; ER19-2671-008; ER19-2672-008; ER20-1073-007; ER20-2510-007; ER20-2512-007; ER20-2515-007; ER20-2663-007; ER21-2406-006; ER21-2407-006; ER21-2408-006; ER21-2409-006; ER21-2638-006; ER22-734-005; ER22-2028-004; ER22-2421-003; ER22-2423-003; ER22-2424-002; ER22-2425-003; ER22-2426-002; ER22-2427-003; ER22-2428-002; ER23-1237-001; ER23-2186-001; ER23-2188-001; ER23-2190-001; ER23-2512-001; ER23-2513-001; ER23-2522-002; ER23-2523-002; ER23-2524-002.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     SR Lambert II, LLC, SR Lambert I, LLC, SR Georgetown, LLC, SR Canadaville Lessee, LLC, SR Canadaville, LLC, SR DeSoto III, LLC, SR DeSoto III Lessee, LLC, SR DeSoto II, LLC, SR Snipesville III, LLC, SR McKellar Lessee, LLC, SR Cedar Springs, LLC, SR McKellar, LLC, SR Clay, LLC, SR Bell Buckle, LLC, SR DeSoto I Lessee, LLC, SR DeSoto I, LLC, SR Hazlehurst, LLC, SR Arlington, LLC, SR Perry, LLC, SR Snipesville II, LLC, SR Lumpkin, LLC, SR Georgia Portfolio II Lessee, LLC, Lancaster Solar LLC, SR Snipesville, LLC, SR Georgia Portfolio I MT, LLC, SR Baxley, LLC, Odom Solar LLC, SR Terrell, LLC, SR Arlington II MT, LLC, SR Arlington II, LLC, SR Meridian III, LLC, SR Hazlehurst III, LLC, SR Millington, LLC, Hattiesburg Farm, LLC, SR South Loving LLC, Simon Solar, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Triennial Market Power Analysis for Southeast Region of Simon Solar, LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5476.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 3/4/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER17-1320-004; ER17-2281-003; ER17-2282-003; ER19-135-003; ER20-64-003; ER20-65-003; ER21-653-003; ER21-654-003; ER21-856-004; ER21-857-004; ER21-1396-002; ER21-1397-002; ER21-2689-002; ER21-2690-002; ER21-2764-002; ER21-2769-002; ER22-19-002; ER22-20-002; ER22-215-002; ER22-216-002; ER22-2399-001; ER22-2400-001; ER22-2401-001; ER22-2403-001; ER22-2404-001; ER22-2405-001; ER22-2406-001; ER22-2407-001; ER22-2410-001; ER22-2411-001; ER22-2412-001; ER22-2413-001; ER22-2816-001; ER22-2817-001; ER23-726-001; ER23-727-001; ER23-1413-001; ER23-1414-001; ER23-1415-001; ER23-1416-001; ER23-2933-001; ER23-2934-001; ER24-672-001; ER24-673-001.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     PGR 2022 Lessee 5, LLC, Moonshot Solar, LLC, PGR 2022 Lessee 4, LLC, Cane Creek Solar, LLC, PGR 2022 Lessee 1, LLC, Virginia Line Solar, LLC, PGR 2021 Lessee 18, LLC, Landrace Holdings, LLC, PGR 2022 Lessee 2, LLC, Fresh Air Energy XXIII, LLC, Eastover Solar LLC, PGR 2021 Lessee 17, LLC, PGR 2021 Lessee 9, LLC, Bulldog Solar, LLC, PGR 2021 Lessee 13, LLC, Sonny Solar, LLC, PGR 2021 Lessee 19, LLC, Allora Solar, LLC, PGR 2021 Lessee 15, LLC, Gunsight Solar, LLC, PGR 2021 Lessee 12, LLC, Cabin Creek Solar, LLC, PGR 2021 Lessee 11, LLC, Phobos Solar, LLC, PGR 2021 Lessee 2, LLC, Beulah Solar, LLC, PGR 2021 Lessee 1, LLC, Stanly Solar, LLC, PGR 2021 Lessee 7, LLC, Highest Power Solar, LLC, PGR 2021 Lessee 5, LLC, Lick Creek Solar, LLC, PGR 2020 Lessee 8, LLC, Sugar Solar, LLC, Trent River Solar, LLC, PGR Lessee P, LLC, PGR Lessee O, LLC, Centerfield Cooper Solar, LLC, TWE Bowman Solar Project, LLC, PGR Lessee L, LLC, Peony Solar LLC, Champion Solar, LLC, Swamp Fox Solar, LLC, Odyssey Solar, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Triennial Market Power Analysis for Southeast Region of Odyssey Solar, LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5471.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 3/4/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER17-1794-006.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Innovative Solar 42, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Triennial Market Power Analysis for Southeast Region of Innovative Solar 42, LLC.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5482.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 3/4/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER18-1906-008; ER16-221-009; ER18-1907-008; ER17-1757-009; ER10-1767-011; ER21-2349-003; ER13-2349-010; ER10-1541-012; ER10-1642-013; ER21-2350-003.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     MS Sunflower Project Company, LLC, EWO Marketing, Inc., Entergy Power, LLC, EAM Nelson Holding, LLC, AR Searcy Project Company, LLC, Entergy Texas, Inc., Entergy New Orleans, LLC, Entergy Mississippi, LLC, Entergy Louisiana, LLC, Entergy Arkansas, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Triennial Market Power Analysis for Central Region of Entergy Arkansas, LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     12/29/23.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20231229-5449.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 2/27/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER19-2429-009.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Brookfield Smoky Mountain Hydropower LP.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Triennial Market Power Analysis for Southeast Region of Brookfield Smoky Mountain Hydropower LP.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5468.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 3/4/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER21-1755-006; ER23-1642-003; ER14-2498-014; ER14-2500-014.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Newark Energy Center, LLC, EIF Newark, LLC, Stored Solar J&amp;WE, LLC, Hartree Partners, LP.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Triennial Market Power Analysis Southeast Region of Newark Energy Center, LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5481.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 3/4/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-8-001.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     PJM Interconnection, L.L.C.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Tariff Amendment: Submission of Response to Deficiency Letter, ISA, SA No. 7092, ICSA, SA No. 7093 to be effective 12/1/2023.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5434.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 1/23/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-804-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     PATH West Virginia Transmission Company, PJM Interconnection, L.L.C.
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: PATH West Virginia Transmission Company submits tariff filing per 35.13(a)(2)(iii: PATH Notice of Cancellation of OATT Attachments H-19, H-19A, and H-19B to be effective 1/10/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5406.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 1/23/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-805-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Entergy Arkansas, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: Updated LBA Agreement to be effective 3/2/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5427.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 1/23/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-806-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Entergy Arkansas, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: EAL-AECC Wholesale Distribution Agreement to be effective 3/2/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5428.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 1/23/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-807-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Versant Power.
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: Establish Regulatory Asset for Recovery Through Rates for MPD to be effective 6/1/2025.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/3/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240103-5074.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 1/24/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-808-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Southwest Power Pool, Inc.
                    <PRTPAGE P="1093"/>
                </P>
                <P>
                    <E T="03">Description:</E>
                     205(d) Rate Filing: 1139R7 Southwestern Public Service Company NITSA NOA Cancellation to be effective 12/19/2023.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/3/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240103-5078.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 1/24/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-809-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 WMPA, Service Agreement No. 5556; Queue No. AE1-123 to be effective 3/4/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/3/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240103-5102.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 1/24/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-810-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 ISA, Service Agreement No. 7151; Queue No. AE1-059 to be effective 12/4/2023.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/3/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240103-5133.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 1/24/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.  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: January 3, 2024.</DATED>
                    <NAME>Debbie-Anne A. Reese,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00222 Filed 1-8-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</SUBJECT>
                <P>Take notice that the Commission has received the following Natural Gas Pipeline Rate and Refund Report filings:</P>
                <HD SOURCE="HD1">Filings Instituting Proceedings</HD>
                <P>
                    <E T="03">Docket Numbers:</E>
                     PR24-32-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Columbia Gas of Ohio, Inc.
                </P>
                <P>
                    <E T="03">Description:</E>
                     284.123 Rate Filing: COH Change SOC language effective 1-3-2024 to be effective 1/3/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/3/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240103-5034.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 1/24/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     RP24-297-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Texas Eastern Transmission, LP.
                </P>
                <P>
                    <E T="03">Description:</E>
                     4(d) Rate Filing: Negotiated Rates—JPM Chase to JPM Ventures 8987392 eff 1-1-24 to be effective 1/1/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5364.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 1/16/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     RP24-298-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Sabine Pipe Line LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     4(d) Rate Filing: Normal filing 2024-7.26-4.5 to be effective 1/1/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24. 
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5380.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 1/16/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     RP24-299-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Gas Transmission Northwest LLC. 
                </P>
                <P>
                    <E T="03">Description:</E>
                     4(d) Rate Filing: Amendment to NR18638—Name Change to Crescent Point to be effective 1/1/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     1/2/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240102-5429.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 1/16/24.
                </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>
                    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>
                    eFiling is encouraged. More detailed information relating to filing requirements, interventions, protests, service, and qualifying facilities filings can be found at: 
                    <E T="03">https://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: January 3, 2024.</DATED>
                    <NAME>Debbie-Anne A. Reese,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00224 Filed 1-8-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-OPPT-2023-0627; FRL-11598-01-OCSPP]</DEPDOC>
                <SUBJECT>TSCA New Chemicals Program Decision Framework for Hazard Identification of Eye Irritation and Corrosion; 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) is announcing the availability of a new document supporting the new chemicals program under the Toxic Substances Control Act (TSCA) titled “New Chemicals Program Decision Framework for Hazard Identification of Eye Irritation and Corrosion.” The document provides a decision framework for use by the Office of Pollution Prevention and Toxics (OPPT) New Chemicals Division (NCD) for identification of eye irritation or corrosion hazards for new chemical substances based on prioritization of reproducible, human-relevant data. The Framework supports EPA's mandate under TSCA to promote the development and implementation of alternative test methods and strategies, or New Approach Methodologies 
                        <PRTPAGE P="1094"/>
                        (NAMs), to reduce, refine or replace vertebrate animal testing and provide information of equivalent or better scientific quality and relevance for assessing risks of injury to health or the environment.
                    </P>
                </SUM>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The docket for this action, identified by docket identification (ID) number EPA-HQ-OPPT-2023-0627, is available online at 
                        <E T="03">http://www.regulations.gov.</E>
                         Additional instructions for 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>
                        <E T="03">For technical information contact:</E>
                         Renee Beardslee, New Chemical Division (7405M), Office of Pollution Prevention and Toxics, Environmental Protection Agency, 1200 Pennsylvania Ave. NW, Washington, DC 20460-0001: telephone number: (202) 564-8787; email address: 
                        <E T="03">beardslee.renee@epa.gov.</E>
                    </P>
                    <P>
                        <E T="03">For general information contact:</E>
                         The TSCA-Hotline, ABVI-Goodwill, 422 South Clinton Ave., Rochester, NY 14620; telephone number: (202) 554-1404; email address: 
                        <E T="03">TSCA-Hotline@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Does this action apply to me?</HD>
                <P>
                    This action is directed to the public in general. This notice may be of specific interest to persons who are or may be interested in risk assessments of new chemical substances under TSCA (
                    <E T="03">e.g.,</E>
                     submitters of TSCA 5 notices, industry, non-governmental organizations (NGOs), and academia). Since other entities may also be interested, the Agency has not attempted to describe all the specific entities that may be affected by this action.
                </P>
                <HD SOURCE="HD1">II. What action is the Agency taking?</HD>
                <P>EPA is announcing the availability of a new decision framework for use by the New Chemicals Division (NCD) of the Office of Pollution Prevention and Toxics (OPPT) for identification of eye irritation or corrosion hazards for new chemical substances based on prioritization of reproducible, human-relevant data. The document supports EPA's efforts to develop NAMs that do not require vertebrate animal testing and furthers the agency's commitment to reduce and replace the use of vertebrate animals in the testing of chemical substances and mixtures.</P>
                <P>TSCA section 4(h)(2)(A) directs EPA to “promote the development and implementation of alternative test methods and strategies to reduce, refine, or replace vertebrate animal testing and provide information of equivalent or better scientific quality and relevance for assessing risks of injury to health or the environment.”</P>
                <P>To incorporate alternative test methods and strategies, or NAMs, data for eye irritation and corrosion hazard identification into the new chemicals program risk assessment process, NCD developed a framework for new chemical risk assessments that prioritizes reproducible, human-relevant in vitro data. The Framework is based upon existing peer-reviewed literature, accepted Organization for Economic Cooperation and Development (OECD) test guidelines, and other existing accepted risk assessment approaches.</P>
                <P>NCD is responsible for conducting risk assessments for new chemical substances submitted under TSCA section 5 authority. NCD expects multiple benefits from the incorporation of this proposed Framework in its assessment including: (1) progress towards fulfilling TSCA section 4(h)(2) statutory requirements; (2) transparency for stakeholders regarding EPA's process of hazard identification of eye irritation and corrosion for new chemical submissions; (3) clear scientific rationale for identification of eye irritation and corrosion hazards for human health assessors leading to improved consistency across final new chemical risk assessments; and (4) use of the most reproducible, human-relevant scientific data for decision-making.</P>
                <HD SOURCE="HD1">III. Does this Framework impose binding requirements?</HD>
                <P>This document is not binding on the Agency or any outside parties, and the Agency may depart from it where circumstances warrant and without prior notice. While EPA has made every effort to ensure the accuracy of the discussion in the Framework, the obligations of EPA and the regulated community are determined by statutes, regulations, or other legally binding documents. In the event of a conflict between the discussion in the Framework document and any statute, regulation, or other legally binding document, the Framework document will not be controlling.</P>
                <HD SOURCE="HD1">IV. Is this Framework subject to the Paperwork Reduction Act (PRA)?</HD>
                <P>
                    This action does not contain any new or revised information collections or burden subject to additional OMB approval under the PRA, 44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                     Burden is defined in 5 CFR 1320.3(b). Information collection activities contained in the TSCA new chemicals program are already approved by OMB under the PRA and are assigned OMB Control No. 2070-0038 (EPA ICR No. 1188.14).
                </P>
                <P>
                    <E T="03">Authority:</E>
                     15 U.S.C. 2604 
                    <E T="03">et seq.</E>
                </P>
                <SIG>
                    <DATED>Dated: January 3, 2024.</DATED>
                    <NAME>Michal Freedhoff,</NAME>
                    <TITLE>Assistant Administrator, Office of Chemical Safety and Pollution Prevention.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00169 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL DEPOSIT INSURANCE CORPORATION</AGENCY>
                <SUBJECT>Sunshine Act Meetings</SUBJECT>
                <PREAMHD>
                    <HD SOURCE="HED">TIME AND DATE:</HD>
                    <P>9:30 a.m. on Friday, January 5, 2024.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">PLACE:</HD>
                    <P>The meeting was held via video conference on the internet.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">STATUS:</HD>
                    <P>Closed.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">MATTERS TO BE CONSIDERED:</HD>
                    <P>The Special Review Committee of the Federal Deposit Insurance Corporation met to consider matters related to the Corporation's corporate activities within its authority to act on behalf of the Federal Deposit Insurance Corporation. In calling the meeting, the Special Review Committee determined, by the unanimous vote of Director Jonathan P. McKernan and Director Michael J. Hsu (Acting Comptroller of the Currency), that Corporation business required its consideration of the matters which were to be the subject of this meeting on less than seven days' notice to the public; that no earlier notice of the meeting was practicable; that the public interest did not require consideration of the matters in a meeting open to public observation; and that the matters could be considered in a closed meeting by authority of subsections (c)(2) and (c)(4) of the “Government in the Sunshine Act” (5 U.S.C. 552b(c)(2) and (c)(4)).</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">CONTACT PERSON FOR MORE INFORMATION:</HD>
                    <P>Requests for further information concerning the meeting may be directed to Debra A. Decker, Executive Secretary of the Corporation, at 202-898-8748.</P>
                </PREAMHD>
                <SIG>
                    <DATED>Dated: January 5, 2024.</DATED>
                    <FP>Federal Deposit Insurance Corporation.</FP>
                    <NAME>James P. Sheesley,</NAME>
                    <TITLE>Assistant Executive Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00333 Filed 1-5-24; 4:15 pm]</FRDOC>
            <BILCOD>BILLING CODE 6714-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL RESERVE SYSTEM</AGENCY>
                <SUBJECT>Formations of, Acquisitions by, and Mergers of Bank Holding Companies</SUBJECT>
                <P>
                    The companies listed in this notice have applied to the Board for approval, 
                    <PRTPAGE P="1095"/>
                    pursuant to the Bank Holding Company Act of 1956 (12 U.S.C. 1841 
                    <E T="03">et seq.</E>
                    ) (BHC Act), Regulation Y (12 CFR part 225), and all other applicable statutes and regulations to become a bank holding company and/or to acquire the assets or the ownership of, control of, or the power to vote shares of a bank or bank holding company and all of the banks and nonbanking companies owned by the bank holding company, including the companies listed below.
                </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 the BHC Act (12 U.S.C. 1842(c)).
                </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 7, 2024.</P>
                <P>
                    A. Federal Reserve Bank of Atlanta (Erien O. Terry, Assistant Vice President) 1000 Peachtree Street NE, Atlanta, Georgia 30309; Comments can also be sent electronically to 
                    <E T="03">Applications.Comments@atl.frb.org</E>
                    ]:
                </P>
                <P>
                    1. 
                    <E T="03">Eureka Investor Group, Inc., Birmingham, Alabama;</E>
                     to become a bank holding company by acquiring Eureka Homestead Bancorp, Inc., a savings and loan holding company, and thereby indirectly acquire Eureka Homestead, a savings association subsidiary, both of Metairie, Louisiana. In addition, Eureka Homestead Bancorp, Inc. will convert from a savings and loan holding company to a bank holding company in connection with Eureka Homestead's conversion from a savings association to a national bank.
                </P>
                <P>Board of Governors of the Federal Reserve System.</P>
                <SIG>
                    <NAME>Michele Taylor Fennell,</NAME>
                    <TITLE>Deputy Associate Secretary of the Board.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00166 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">GOVERNMENT ACCOUNTABILITY OFFICE</AGENCY>
                <SUBJECT>Request for Medicare Payment Advisory Commission (MedPAC) Nominations</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>U.S. Government Accountability Office.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Request for letters of nomination and resumes.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Balanced Budget Act of 1997 established the Medicare Payment Advisory Commission (MedPAC) and gave the Comptroller General responsibility for appointing its members. The U.S. Government Accountability Office (GAO) is now accepting nominations for MedPAC appointments that will be effective in May 2024. Nominations should be sent to the email address listed below. Acknowledgement of receipt will be provided within a week of submission.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Letters of nomination and resumes should be submitted no later than February 9, 2024, to ensure adequate opportunity for review and consideration of nominees prior to appointment.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Submit letters of nomination and resumes to 
                        <E T="03">MedPACappointments@gao.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Gregory Giusto at (202) 512-8268 or 
                        <E T="03">giustog@gao.gov</E>
                         if you do not receive an acknowledgement or need additional information. For general information, contact GAO's Office of Public Affairs at (202) 512-4800.
                    </P>
                    <P>
                        <E T="03">Authority:</E>
                         42 U.S.C. 1395b-6.
                    </P>
                    <SIG>
                        <NAME>Gene L. Dodaro,</NAME>
                        <TITLE>Comptroller General of the United States.</TITLE>
                    </SIG>
                </FURINF>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00181 Filed 1-8-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:</E>
                     Disease, Disability, and Injury Prevention and Control Special Emphasis Panel (SEP)-RFA-PS-24-040, Understanding Infant Feeding Preferences, Practices, and Outcomes for Mothers and other Parents with HIV in the United States.
                </P>
                <P>
                    <E T="03">Date:</E>
                     March 28, 2024.
                </P>
                <P>
                    <E T="03">Time:</E>
                     10 a.m.-5 p.m., EDT.
                </P>
                <P>
                    <E T="03">Place:</E>
                     Videoconference.
                </P>
                <P>
                    <E T="03">Agenda:</E>
                     To review and evaluate grant applications.
                </P>
                <P>
                    <E T="03">For Further Information Contact:</E>
                     Seraphine Pitt Barnes, Ph.D., M.P.H., C.H.E.S., Scientific Review Officer, National Center for HIV, Viral Hepatitis, STD, and TB Prevention, Centers for Disease Control and Prevention, 1600 Clifton Road NE, Mailstop H24-6, Atlanta, Georgia 30329-4027. Telephone: (770) 488-6115; Email: 
                    <E T="03">SPittBarnes@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-00214 Filed 1-8-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>Centers for Medicare &amp; Medicaid Services</SUBAGY>
                <DEPDOC>[Document Identifiers: CMS-10398 #43, #45, and #48]</DEPDOC>
                <SUBJECT>Medicaid and Children's Health Insurance Program (CHIP) Generic Information Collection Activities: Proposed Collection; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Centers for Medicare &amp; Medicaid Services, Health and Human Services (HHS).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <PRTPAGE P="1096"/>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        On May 28, 2010, the Office of Management and Budget (OMB) issued Paperwork Reduction Act (PRA) guidance related to the “generic” clearance process. Generally, this is an expedited process by which agencies may obtain OMB's approval of collection of information requests that are “usually voluntary, low-burden, and uncontroversial collections,” do not raise any substantive or policy issues, and do not require policy or methodological review. The process requires the submission of an overarching plan that defines the scope of the individual collections that would fall under its umbrella. On October 23, 2011, OMB approved our initial request to use the generic clearance process under control number 0938-1148 (CMS-10398). It was last approved on April 26, 2021, via the standard PRA process which included the publication of 60- and 30-day 
                        <E T="04">Federal Register</E>
                         notices. The scope of the April 2021 umbrella accounts for Medicaid and CHIP State plan amendments, waivers, demonstrations, and reporting. This 
                        <E T="04">Federal Register</E>
                         notice seeks public comment on one or more of our collection of information requests that we believe are generic and fall within the scope of the umbrella. Interested persons are invited to submit comments regarding our burden estimates or any other aspect of this collection of information, including: the necessity and utility of the proposed information collection for the proper performance of the agency's functions, the accuracy of the estimated burden, ways to enhance the quality, utility and clarity of the information to be collected, and the use of automated collection techniques or other forms of information technology to minimize the information collection burden.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received by January 23, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>When commenting, please reference the applicable form number (CMS-10398 #see below) and the OMB control number (0938-1148). To be assured consideration, comments and recommendations must be submitted in any one of the following ways:</P>
                    <P>
                        1. 
                        <E T="03">Electronically.</E>
                         You may send your comments electronically to 
                        <E T="03">http://www.regulations.gov.</E>
                         Follow the instructions for “Comment or Submission” or “More Search Options” to find the information collection document(s) that are accepting comments.
                    </P>
                    <P>
                        2. 
                        <E T="03">By regular mail.</E>
                         You may mail written comments to the following address: CMS, Office of Strategic Operations and Regulatory Affairs, Division of Regulations Development, Attention: CMS-10398 (#__)/OMB control number: 0938-1148, Room C4-26-05, 7500 Security Boulevard, Baltimore, Maryland 21244-1850.
                    </P>
                    <P>
                        To obtain copies of a supporting statement and any related forms for the proposed collection(s) summarized in this notice, please access the CMS PRA website by copying and pasting the following web address into your web browser: 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Legislation/PaperworkReductionActof1995/PRAListing.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>William N. Parham at (410) 786-4669.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Following is a summary of the use and burden associated with the subject information collection(s). More detailed information can be found in the collection's supporting statement and associated materials (see 
                    <E T="02">ADDRESSES</E>
                    ).
                </P>
                <HD SOURCE="HD1">Generic Information Collections</HD>
                <P>
                    <E T="03">1. Title of Information Collection:</E>
                     Certified Community Behavioral Health Clinic (CCBHC) Cost Report; 
                    <E T="03">Type of Information Collection Request:</E>
                     Revision of an active collection of information request; 
                    <E T="03">Use:</E>
                     The CCBHC cost report allows clinics in the demonstration to calculate Prospective Payment System (PPS) rates using clinic-specific cost and visit data associated with delivery of the nine statutory services as outlined under the authorizing Protecting Access to Medicare Act (PAMA) (Pub. L. 113-93) at section 223(D) Scope of Services. Currently CCBHCs use the cost report to calculate rates based on the existing CC PPS-1 daily, or CC PPS-2 monthly rate that do not include separate crisis rate options. Calculation of the new daily and monthly special crisis services PPS rates required CMS to revise the existing CCBHC cost report to include addition worksheets to address the new crisis rate offerings being finalized in the CCBHC Technical Guide. SCS rates would be effective beginning January 1, 2024, for any existing states that may be interested in implementing either CC PPS-3 or CC PPS-4, and new states entering the program by July 2024 will have the option to choose from among the four PPS rate options made available under the updated Technical Guide and CCBHC cost report.
                </P>
                <P>States and clinics selecting either the CC PPS-3 or CC PPS-4 crisis rate methodology will require additional time to separate costs and visit data for up to three special crisis services rates. CCBHCs in states that choose CC PPS-2 rate methodology will require additional time to gather data for special populations and account for outlier thresholds.</P>
                <P>
                    Because use of this cost report involves participation in the CCBHC demonstration program, the information is expected to be collected annually, assuming rates are trended forward for the second year of the program using the Medicare Economic Index (MEI), rebased in the third year of the demonstration and trended forward for the fourth year of the demonstration using the MEI. However, if the state requires CCBHCs to rebase rates for other years of the demonstration using CCBHC cost report data, the provider would be required to complete the cost report each time the state rebases the rate. CMS does also require CCBHC demonstration states to submit cost reports in trended years although rates may only reflect changes based on MEI adjustment for inflationary changes. 
                    <E T="03">Form Number:</E>
                     CMS-10398 #43 (OMB control number: 0938-1148); 
                    <E T="03">Frequency:</E>
                     Annual; 
                    <E T="03">Affected Public:</E>
                     Private Sector (Businesses or other for profits and Not for profit institutions) and State, Local, or Tribal Governments; 
                    <E T="03">Number of Respondents:</E>
                     60; 
                    <E T="03">Total Annual Responses:</E>
                     60; 
                    <E T="03">Total Annual Hours: 3,389.</E>
                     (For policy questions regarding this collection contact: Beverly Boston at 410-786-4186.)
                </P>
                <P>
                    <E T="03">2. Title of Information Collection:</E>
                     Certified Community Behavioral Health Clinic (CCBHC) 2024 State Proposal Demonstration Application; 
                    <E T="03">Type of Information Collection Request:</E>
                     Revision of an active collection of information request; 
                    <E T="03">Use:</E>
                     Based on recent extension and expansion of the CCBHC Demonstration under section 11001 of Bipartisan Safer Communities Act 
                    <SU>1</SU>
                    <FTREF/>
                     (BSCA) of 2022, the State Proposal Demonstration Application is required to be completed by existing CCBHC grantee states and submitted to the Centers for Medicare &amp; Medicaid Services (CMS) and the Substance Abuse and Mental Health Services Administration (SAMHSA) to determine state readiness and eligibility to be selected as one of the 10 new states added to the CCBHC demonstration in 2024 and every two years thereafter per the BSCA legislation. The awarding of Planning Grants to states was the first phase of a two-phase process. Phase II will consist of participation in the demonstration. 
                    <E T="03">Form Number:</E>
                     CMS-10398 #45 (OMB control number: 0938-1148); 
                    <E T="03">Frequency:</E>
                     One time and On occasion; 
                    <E T="03">Affected Public:</E>
                     State, Local, or Tribal Governments; 
                    <E T="03">Number of Respondents:</E>
                     30; 
                    <E T="03">
                        Total Annual 
                        <PRTPAGE P="1097"/>
                        Responses:
                    </E>
                     30; 
                    <E T="03">Total Annual Hours: 1,790.</E>
                     (For policy questions regarding this collection contact: Beverly Boston at 410-786-4186.)
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         Bipartisan Safer Communities Act.
                    </P>
                </FTNT>
                <P>
                    <E T="03">3. Title of Information Collection:</E>
                     Behavioral Health Clinic Quality Data Reporting; 
                    <E T="03">Type of Information Collection Request:</E>
                     Revision of an active collection of information request; 
                    <E T="03">Use:</E>
                     This Information Collection concerns the Behavioral Health Clinic Quality Data Reporting Template (hereinafter “Reporting Template” or “Template”), developed in partnership with the Substance Abuse and Mental Health Services Administration (SAMHSA) and the Assistant Secretary for Planning and Evaluation (ASPE) (collectively, “the Agencies”). The Reporting Template is designed to collect quality measure data and to report at the clinic level. The Agencies developed the Template to provide states and clinics with a streamlined and structured tool to report quality measures data. The Reporting Template aims to eliminate the time required for states or clinics to develop their own reporting templates for quality measure data reporting and minimizes inconsistencies in reporting. Furthermore, the Reporting Template, with its accompanying instructions, support an innovative approach to improve behavioral health, a key focus of health care reform. 
                    <E T="03">Form Number:</E>
                     CMS-10398 (#48) (OMB control number: 0938-1148); 
                    <E T="03">Frequency:</E>
                     Annual; 
                    <E T="03">Affected Public:</E>
                     Private Sector (Businesses or other for profits and Not for profit institutions) and State, Local, or Tribal Governments; 
                    <E T="03">Number of Respondents:</E>
                     429; 
                    <E T="03">Total Annual Responses:</E>
                     1,009; 
                    <E T="03">Total Annual Hours: 6,814.</E>
                     (For policy questions regarding this collection contact: Beverly Boston at 410-786-4186.)
                </P>
                <SIG>
                    <DATED>Dated: January 4, 2024.</DATED>
                    <NAME>William N. Parham, III,</NAME>
                    <TITLE>Director, Division of Information Collections and Regulatory Impacts, Office of Strategic Operations and Regulatory Affairs.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00205 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4120-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>Food and Drug Administration</SUBAGY>
                <DEPDOC>[Docket No. FDA-2020-N-0026]</DEPDOC>
                <SUBJECT>Issuance of Priority Review Voucher; Rare Pediatric Disease Product</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 announcing the issuance of a priority review voucher to the sponsor of a rare pediatric disease product application. The Federal Food, Drug, and Cosmetic Act (FD&amp;C Act) authorizes FDA to award priority review vouchers to sponsors of approved rare pediatric disease product applications that meet certain criteria. FDA is required to publish notice of the award of the priority review voucher. FDA has determined that CASGEVY (exagamglogene autotemcel), manufactured by Vertex Pharmaceuticals, Inc., meets the criteria for a priority review voucher.</P>
                </SUM>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Myrna Hanna, Center for Biologics Evaluation and Research, Food and Drug Administration, 10903 New Hampshire Ave., Bldg. 71, Rm. 7301, Silver Spring, MD 20993-0002, 240-402-7911.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>FDA is announcing the issuance of a priority review voucher to the sponsor of an approved rare pediatric disease product application. Under section 529 of the FD&amp;C Act (21 U.S.C. 360ff), FDA will award priority review vouchers to sponsors of approved rare pediatric disease product applications that meet certain criteria. FDA has determined that CASGEVY (exagamglogene autotemcel), manufactured by Vertex Pharmaceuticals, Inc., meets the criteria for a priority review voucher.</P>
                <P>CASGEVY (exagamglogene autotemcel) is indicated for treatment of sickle cell disease in patients 12 years of age and older with recurrent vaso-occlusive crises.</P>
                <P>
                    For further information about the Rare Pediatric Disease Priority Review Voucher Program and for a link to the full text of section 529 of the FD&amp;C Act, go to 
                    <E T="03">https://www.fda.gov/industry/developing-products-rare-diseases-conditions/rare-pediatric-disease-rpd-designation-and-voucher-programs.</E>
                     For further information about CASGEVY (exagamglogene autotemcel), go to the Center for Biologics Evaluation and Research's Approved Cellular and Gene Therapy Products website at 
                    <E T="03">https://www.fda.gov/vaccines-blood-biologics/cellular-gene-therapy-products/approved-cellular-and-gene-therapy-products.</E>
                </P>
                <SIG>
                    <DATED>Dated: January 4, 2024.</DATED>
                    <NAME>Lauren K. Roth,</NAME>
                    <TITLE>Associate Commissioner for Policy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00263 Filed 1-8-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>Food and Drug Administration</SUBAGY>
                <DEPDOC>[Docket No. FDA-2014-N-0987]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities; Proposed Collection; Comment Request; Generic Clearance for the Collection of Qualitative Data on Tobacco Products and Communications</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 or Agency) is announcing an opportunity for public comment on the proposed collection of certain information by the Agency. Under the Paperwork Reduction Act of 1995 (PRA), Federal Agencies are required to publish notice in the 
                        <E T="04">Federal Register</E>
                         concerning each proposed collection of information, including each proposed extension of an existing collection of information, and to allow 60 days for public comment in response to the notice. This notice solicits comments on the collection of qualitative data on tobacco products and communications.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Either electronic or written comments on the collection of information must be submitted by March 11, 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. 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 March 11, 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 
                    <PRTPAGE P="1098"/>
                    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-2014-N-0987 for “Generic Clearance for the Collection of Qualitative Data on Tobacco Products and Communications.” 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>
                        JonnaLynn Capezzuto, Office of Operations, Food and Drug Administration, Three White Flint North, 10A-12M, 11601 Landsdown St., North Bethesda, MD 20852, 301-796-3794, 
                        <E T="03">PRAStaff@fda.hhs.gov</E>
                        .
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Under the PRA (44 U.S.C. 3501-3521), Federal Agencies must obtain approval from the Office of Management and Budget (OMB) for each collection of information they conduct or sponsor. “Collection of information” is defined in 44 U.S.C. 3502(3) and 5 CFR 1320.3(c) and includes Agency requests or requirements that members of the public submit reports, keep records, or provide information to a third party. Section 3506(c)(2)(A) of the PRA (44 U.S.C. 3506(c)(2)(A)) requires Federal Agencies to provide a 60-day notice in the 
                    <E T="04">Federal Register</E>
                     concerning each proposed collection of information, including each proposed extension of an existing collection of information, before submitting the collection to OMB for approval. To comply with this requirement, FDA is publishing notice of the proposed collection of information set forth in this document.
                </P>
                <P>With respect to the following collection of information, FDA invites comments on these topics: (1) whether the proposed collection of information is necessary for the proper performance of FDA's functions, including whether the information will have practical utility; (2) the accuracy of FDA's estimate of the burden of the proposed collection of information, including the validity of the methodology and assumptions used; (3) ways to enhance the quality, utility, and clarity of the information to be collected; and (4) ways to minimize the burden of the collection of information on respondents, including through the use of automated collection techniques, when appropriate, and other forms of information technology.</P>
                <HD SOURCE="HD1">Generic Clearance for the Collection of Qualitative Data on Tobacco Products and Communications</HD>
                <HD SOURCE="HD2">OMB Control Number 0910-0796—Extension</HD>
                <P>This information collection supports Food and Drug Administration (FDA, us, or we) programs. Under section 1003(d)(2)(D) of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 393(d)(2)(D)), FDA is authorized to conduct educational and public information programs.</P>
                <P>
                    In conducting studies relating to the regulation and communications related to tobacco products, FDA will need to employ formative qualitative research including but not limited to focus groups, usability and/or psychometric testing, indepth interviews (IDIs), cognitive interviews and asynchronous qualitative discussions (
                    <E T="03">e.g.,</E>
                     online journaling or web-based discussion boards), naturalistic observation and ethnographic studies to assess knowledge and perceptions about tobacco-related topics with specific target audiences. The information collected will serve four major purposes. First, foundational research will provide critical knowledge and insights about intended audiences. FDA must first understand people's knowledge of, perceptions of, and reactions to tobacco related topics prior to developing survey/research questions as well as stimuli for experimental studies. Second, formative research will provide information about people's responses, thoughts, and feelings regarding potential creative messaging, or stimuli. Third, by collecting communications usability information, FDA will be able to serve and respond to the ever-changing demands of consumers of tobacco products. Additionally, we will be able to determine the best way to communicate with intended audiences around tobacco prevention and cessation. Fourth, cognitive testing will allow FDA to assess consumer understanding of survey/research questions and study stimuli. Focus groups and/or IDIs with a sample of the intended audience will allow FDA to refine the survey/research questions and study stimuli while they are still in the developmental stage. FDA will collect, and interpret information gathered through this generic clearance to: (1) better understand characteristics of the intended audience—its perceptions, 
                    <PRTPAGE P="1099"/>
                    knowledge, attitudes, beliefs, and behaviors—and use these in the development of appropriate survey/research questions, study stimuli, or communications; (2) more efficiently and effectively design survey/research questions and study stimuli; and (3) more efficiently and effectively design experimental studies.
                </P>
                <P>
                    FDA is requesting approval of an extension of this generic clearance for collecting information using qualitative methods (
                    <E T="03">e.g.,</E>
                     interviews, focus groups, asynchronous discussion boards, etc.) for studies involving all tobacco products regulated by FDA. This information will be used to explore concepts of interest and assist in the development of quantitative study proposals, complementing other important research efforts in the Agency. This information may also be used to help identify and develop communication messages, which may be used in education campaigns. Qualitative research plays an important role in gathering information because it allows for an indepth understanding of individuals' attitudes, beliefs, motivations, and feelings. Qualitative research serves the narrowly defined need for direct and informal public opinion on a specific topic.
                </P>
                <P>
                    The number of respondents to be included in each new study may vary, depending on the nature of the study (
                    <E T="03">e.g.,</E>
                     foundational, formative, etc.), approach (synchronous vs. asynchronous, or virtual vs. in person) and the intended audience. Table 1 provides examples of the types of studies that may be administered and estimated burden levels during the 3-year period. Time to read, view, or listen to the message being tested is built into the “Average Burden per Response” figures. FDA estimates the burden of this collection of information as follows:
                </P>
                <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s50,12,12,12,xs80,12">
                    <TTITLE>
                        Table 1—Estimated Annual Reporting Burden 
                        <SU>1</SU>
                    </TTITLE>
                    <BOXHD>
                        <CHED H="1">Type of Interview</CHED>
                        <CHED H="1">
                            Number of 
                            <LI>respondents</LI>
                        </CHED>
                        <CHED H="1">
                            Number of 
                            <LI>responses per </LI>
                            <LI>respondent</LI>
                        </CHED>
                        <CHED H="1">Total annual responses</CHED>
                        <CHED H="1">Average burden per response</CHED>
                        <CHED H="1">Total hours</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">In-Person Individual Indepth Interviews</ENT>
                        <ENT>4,500</ENT>
                        <ENT>1</ENT>
                        <ENT>4,500</ENT>
                        <ENT>1</ENT>
                        <ENT>4,500</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Indepth Interview Screener</ENT>
                        <ENT>22,500</ENT>
                        <ENT>1</ENT>
                        <ENT>22,500</ENT>
                        <ENT>0.083 (5 minutes)</ENT>
                        <ENT>1,875</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Focus Group Screener</ENT>
                        <ENT>56,000</ENT>
                        <ENT>1</ENT>
                        <ENT>56,000</ENT>
                        <ENT>0.25 (15 minutes)</ENT>
                        <ENT>14,000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Focus Group Discussion</ENT>
                        <ENT>252,000</ENT>
                        <ENT>1</ENT>
                        <ENT>252,000</ENT>
                        <ENT>1.5</ENT>
                        <ENT>378,000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Discussion Board Screener</ENT>
                        <ENT>8,000</ENT>
                        <ENT>1</ENT>
                        <ENT>8,000</ENT>
                        <ENT>0.083 (5 minutes)</ENT>
                        <ENT>667</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="01">Discussion Board Participation</ENT>
                        <ENT>100</ENT>
                        <ENT>1</ENT>
                        <ENT>100</ENT>
                        <ENT>1.5</ENT>
                        <ENT>150</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Total</ENT>
                        <ENT/>
                        <ENT/>
                        <ENT/>
                        <ENT/>
                        <ENT>399,192</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         There are no capital costs or operating and maintenance costs associated with this collection of information.
                    </TNOTE>
                </GPOTABLE>
                <P>Our estimated burden for the information collection reflects an overall increase of 384,258 hours and a corresponding increase of 314,926 responses. We attribute this adjustment to the number of study responses used during the current approval and now estimated for the next 3 years. A greater number of qualitative studies will be conducted over the next 3 years due to the need to develop new creative messages and content. Recent years have seen a dramatic change in media. With the shift to digital media, FDA must adapt to communicate effectively in a digital environment. As digital tobacco use prevention/interventions are still in their infancy, we must better understand the types of digital channels available. To impact public health outcomes, we need to understand how to reach our intended audience. New foundational studies are needed (including those on digital metrics, measurement, and implementation). As a result, we have adjusted our burden estimate and revised the number of respondents to the information collection.</P>
                <SIG>
                    <DATED>Dated: January 4, 2024.</DATED>
                    <NAME>Lauren K. Roth,</NAME>
                    <TITLE>Associate Commissioner for Policy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00221 Filed 1-8-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>Food and Drug Administration</SUBAGY>
                <DEPDOC>[Docket No. FDA-2023-N-3168]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities; Submission for Office of Management and Budget Review; Comment Request; Extralabel Drug Use in Animals</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 announcing that a proposed collection of information has been submitted to the Office of Management and Budget (OMB) for review and clearance under the Paperwork Reduction Act of 1995.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Submit written comments (including recommendations) on the collection of information by February 8, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        To ensure that comments on the information collection are received, OMB recommends that written comments be submitted to 
                        <E T="03">https://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. The OMB control number for this information collection is 0910-0325. Also include the FDA docket number found in brackets in the heading of this document.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Rachel Showalter, Office of Operations, Food and Drug Administration, Three White Flint North, 10A-12M, 11601 Landsdown St., North Bethesda, MD 20852, 240-994-7399, 
                        <E T="03">PRAStaff@fda.hhs.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>In compliance with 44 U.S.C. 3507, FDA has submitted the following proposed collection of information to OMB for review and clearance.</P>
                <HD SOURCE="HD1">Extralabel Drug Use in Animals—21 CFR Part 530</HD>
                <HD SOURCE="HD2">OMB Control Number 0910-0325—Extension</HD>
                <P>
                    This information collection supports FDA implementation of section 512 of the Federal Food, Drug, and Cosmetic Act (FD&amp;C Act) (21 U.S.C. 360b), which governs new animal drugs. Agency regulations in 21 CFR part 530 permit FDA, if we find that there is a reasonable probability that the extralabel use of an animal drug may present a risk to public health, to establish a safe level for a residue from 
                    <PRTPAGE P="1100"/>
                    the extralabel use of the drug, and to require the development of an analytical method for the detection of residues above that established safe level. This requirement is codified at § 530.22(b) (21 CFR 530.22(b)).
                </P>
                <P>Although to date, we have not established a safe level for a residue from the extralabel use of any new animal drug and, therefore, have not required the development of analytical methodology, we believe that there may be instances when analytical methodology will be required. We are, therefore, estimating the reporting burden based on two methods being required annually. The requirement to establish an analytical method may be fulfilled by any interested person. We believe that the sponsor of the drug will be willing to develop the method in most cases. Alternatively, FDA, the sponsor, and perhaps a third party may cooperatively arrange for method development. Respondents to the information collection are private sector drug sponsors or veterinary associations, or veterinarians, State, local, and tribal governments, and Federal Agencies.</P>
                <P>
                    In the 
                    <E T="04">Federal Register</E>
                     of August 31, 2023 (88 FR 60213), FDA published a 60-day notice requesting public comment on the proposed collection of information. No comments were received.
                </P>
                <P>We estimate the burden of this collection of information as follows:</P>
                <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s50,12C,12C,12C,12C,12C">
                    <TTITLE>
                        Table 1—Estimated Annual Reporting Burden 
                        <SU>1</SU>
                    </TTITLE>
                    <BOXHD>
                        <CHED H="1">21 CFR Section; activity</CHED>
                        <CHED H="1">
                            Number of
                            <LI>respondents</LI>
                        </CHED>
                        <CHED H="1">
                            Number of
                            <LI>responses per</LI>
                            <LI>respondent</LI>
                        </CHED>
                        <CHED H="1">
                            Total
                            <LI>annual</LI>
                            <LI>responses</LI>
                        </CHED>
                        <CHED H="1">
                            Average
                            <LI>burden per</LI>
                            <LI>response</LI>
                        </CHED>
                        <CHED H="1">
                            Total
                            <LI>hours</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">530.22(b); Submission(s) of analytical method</ENT>
                        <ENT>2</ENT>
                        <ENT>1</ENT>
                        <ENT>2</ENT>
                        <ENT>4,160</ENT>
                        <ENT>8,320</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         There are no capital costs or operating and maintenance costs associated with this collection of information.
                    </TNOTE>
                </GPOTABLE>
                <P>Based on a review of the information collection since our last request for OMB approval, we have made no adjustments to our burden estimate.</P>
                <SIG>
                    <DATED>Dated: January 4, 2024.</DATED>
                    <NAME>Lauren K. Roth,</NAME>
                    <TITLE>Associate Commissioner for Policy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00219 Filed 1-8-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>Food and Drug Administration</SUBAGY>
                <DEPDOC>[Docket No. FDA-2023-N-3490]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities; Submission for Office of Management and Budget Review; Comment Request; Application for Participation in Food and Drug Administration Fellowship and Traineeship Programs</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, Agency, or we) is announcing that a proposed collection of information has been submitted to the Office of Management and Budget (OMB) for review and clearance under the Paperwork Reduction Act of 1995 (PRA).</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Submit written comments (including recommendations) on the collection of information by February 8, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        To ensure that comments on the information collection are received, OMB recommends that written comments be submitted to 
                        <E T="03">https://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. The OMB control number for this information collection is 0910-0780. Also include the FDA docket number found in brackets in the heading of this document.
                    </P>
                </ADD>
                <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>In compliance with 44 U.S.C. 3507, FDA has submitted the following proposed collection of information to OMB for review and clearance.</P>
                <HD SOURCE="HD1">Application for Participation in FDA Fellowship and Traineeship Programs</HD>
                <HD SOURCE="HD2">OMB Control Number 0910-0780—Extension</HD>
                <P>This information collection supports FDA fellowship and traineeship programs. Sections 1104, 1302, 3301, 3304, 3320, 3361, 3393, and 3394 of Title 5 of the United States Code authorize Federal Agencies to rate applicants for Federal jobs. The information collection involves brief online applications completed by applicants applying to FDA's Fellowship and Traineeship programs. These voluntary online applications will allow the Agency to easily and efficiently elicit and review information from students and healthcare professionals who are interested in becoming involved in FDA-wide activities. The process will reduce the time and cost of submitting written documentation to the Agency and lessen the likelihood of applications being misrouted within the Agency mail system. It will assist the Agency in promoting and protecting the public health by encouraging outside persons to share their expertise with FDA.</P>
                <P>
                    In the 
                    <E T="04">Federal Register</E>
                     of September 19, 2023 (88 FR 64438), FDA published a 60-day notice requesting public comment on the proposed collection of information. We received two comments, which were not PRA related and will not be addressed in this document.
                </P>
                <P>FDA estimates the burden of this collection of information as follows:</P>
                <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s50,12,12,12,12,12">
                    <TTITLE>
                        Table 1—Estimated Annual Recordkeeping Burden 
                        <SU>1</SU>
                    </TTITLE>
                    <BOXHD>
                        <CHED H="1">Activity</CHED>
                        <CHED H="1">
                            Number of
                            <LI>respondents</LI>
                        </CHED>
                        <CHED H="1">
                            Number of
                            <LI>responses per</LI>
                            <LI>respondent</LI>
                        </CHED>
                        <CHED H="1">
                            Total annual
                            <LI>responses</LI>
                        </CHED>
                        <CHED H="1">
                            Average
                            <LI>burden per</LI>
                            <LI>response</LI>
                        </CHED>
                        <CHED H="1">Total hours</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Medical Device Fellowship Program</ENT>
                        <ENT>250</ENT>
                        <ENT>1</ENT>
                        <ENT>250</ENT>
                        <ENT>1</ENT>
                        <ENT>250</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <PRTPAGE P="1101"/>
                        <ENT I="01">FDA Traineeship Program</ENT>
                        <ENT>1,000</ENT>
                        <ENT>1</ENT>
                        <ENT>1,000</ENT>
                        <ENT>1</ENT>
                        <ENT>1,000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Total</ENT>
                        <ENT/>
                        <ENT/>
                        <ENT/>
                        <ENT/>
                        <ENT>1,250</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         There are no capital costs or operating and maintenance costs associated with this collection of information.
                    </TNOTE>
                </GPOTABLE>
                <P>Based on a review of the information collection since our last request for OMB approval, we have made no adjustments to our burden estimate.</P>
                <SIG>
                    <DATED>Dated: January 4, 2024.</DATED>
                    <NAME>Lauren K. Roth,</NAME>
                    <TITLE>Associate Commissioner for Policy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00220 Filed 1-8-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>Food and Drug Administration</SUBAGY>
                <DEPDOC>[Docket No. FDA-2023-N-4804]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities; Proposed Collection; Comment Request; Expedited Programs for Serious Conditions—Drugs and Biologics</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 or Agency) is announcing an opportunity for public comment on the proposed collection of certain information by the Agency. Under the Paperwork Reduction Act of 1995 (PRA), Federal Agencies are required to publish notice in the 
                        <E T="04">Federal Register</E>
                         concerning each proposed collection of information, including each proposed extension of an existing collection of information, and to allow 60 days for public comment in response to the notice. This notice solicits comments on information collection pertaining to “Expedited Programs for Serious Conditions—Drugs and Biologics.”
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Submit either electronic or written comments on the collection of information by March 11, 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. 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 March 11, 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-2023-N-4804 for “Expedited Programs for Serious Conditions—Drugs and Biologics.” 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>
                        Amber Sanford, Office of Operations, Food and Drug Administration, Three White Flint North, 10A-12M, 11601 
                        <PRTPAGE P="1102"/>
                        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>
                    Under the PRA (44 U.S.C. 3501-3521), Federal Agencies must obtain approval from the Office of Management and Budget (OMB) for each collection of information they conduct or sponsor. “Collection of information” is defined in 44 U.S.C. 3502(3) and 5 CFR 1320.3(c) and includes Agency requests or requirements that members of the public submit reports, keep records, or provide information to a third party. Section 3506(c)(2)(A) of the PRA (44 U.S.C. 3506(c)(2)(A)) requires Federal Agencies to provide a 60-day notice in the 
                    <E T="04">Federal Register</E>
                     concerning each proposed collection of information, including each proposed extension of an existing collection of information, before submitting the collection to OMB for approval. To comply with this requirement, FDA is publishing notice of the proposed collection of information set forth in this document.
                </P>
                <P>With respect to the following collection of information, FDA invites comments on these topics: (1) whether the proposed collection of information is necessary for the proper performance of FDA's functions, including whether the information will have practical utility; (2) the accuracy of FDA's estimate of the burden of the proposed collection of information, including the validity of the methodology and assumptions used; (3) ways to enhance the quality, utility, and clarity of the information to be collected; and (4) ways to minimize the burden of the collection of information on respondents, including through the use of automated collection techniques, when appropriate, and other forms of information technology.</P>
                <HD SOURCE="HD1">Expedited Programs for Serious Conditions—Drugs and Biologics</HD>
                <HD SOURCE="HD2">OMB Control Number 0910-0765—Extension</HD>
                <P>This information collection supports regulations governing FDA expedited programs for serious conditions. These provisions are set forth in 21 CFR part 312, subpart E and are intended to speed the availability of new therapies to patients with serious conditions, especially when there are no satisfactory alternative therapies, while preserving appropriate standards for safety and effectiveness. The regulations call for earlier attention to drugs that have promise in treating such conditions, including early consultation with FDA for sponsors of such products. Respondents to the information collection are sponsors of drug or biologic product applications submitted to FDA.</P>
                <P>To assist respondents with the information collection, we developed Agency guidance entitled “Guidance for Industry Expedited Programs for Serious Conditions—Drugs and Biologics” (May 2014). The guidance is a resource for information on FDA's policies and procedures related to the following expedited programs for serious conditions: (1) fast track designation, (2) breakthrough therapy designation, (3) accelerated approval, and (4) priority review designation, and describes threshold criteria generally applicable to expedited programs, including what is meant by serious condition, unmet medical need, and available therapy. The guidance addresses the applicability of expedited programs to rare diseases, clarification on available therapy, and additional detail on possible flexibility in manufacturing and product quality. It also clarifies the qualifying criteria for breakthrough therapy designation, provides examples of surrogate endpoints and intermediate clinical endpoints used to support accelerated approval, and priority review.</P>
                <P>In addition, we developed Agency guidance entitled “Expedited Programs for Regenerative Medicine Therapies for Serious Conditions,” (February 2019) describing the criteria for participation in the Regenerative Medicine Advanced Therapy (RMAT) program. The RMAT expedited program was approved as part of the 21st Century CURES Act, signed December 13, 2016. An RMAT product is intended to treat, modify, reverse, or cure serious or life-threatening diseases or conditions, and preliminary clinical evidence indicate that the drug has the potential to address unmet medical needs for such diseases or conditions. This is a Center Biologics Evaluation and Research (CBER) program and is included as an expedited program available for serious conditions.</P>
                <P>For a sponsor or applicant who seeks fast track, priority, breakthrough, RMAT or accelerated approval designation review, approval is required to submit a request showing that the drug product: (1) is intended for a serious or life-threatening condition and (2) has the potential to (a) address an unmet medical need, (b) demonstrate substantial improvement over available therapy, or (c) fill an unmet need to be approved based on a surrogate endpoint. We expect that most information to support a designation request will have been gathered under existing requirements for preparing an investigational new drug (IND), new drug application (NDA), or biologics license application (BLA). If such information has already been submitted to us, the information may be summarized in the designation request. A designation request should include, where applicable, additional information not specified elsewhere by statute or regulation. For example, additional information may be needed to show that a product has the potential to address an unmet medical need where an approved therapy exists for the serious or life-threatening condition to be treated. Such information may include clinical data, published reports, summaries of data and reports, and a list of references. The amount of information and discussion in a designation request should be sufficient to permit a reviewer to assess whether the criteria for fast track, priority, breakthrough, RMAT or accelerated approval designation have been met.</P>
                <P>
                    After we make an expedited programs designation, a sponsor or applicant may submit a premeeting package that may include additional information supporting a request to participate in certain expedited programs. The premeeting package serves as background information for the meeting and should support the intended objectives of the meeting. As with the request for expedited programs designation, we expect that most sponsors or applicants will have gathered such information to meet existing requirements for preparing an IND, NDA, or BLA. These may include descriptions of clinical safety and efficacy trials not conducted under an IND (
                    <E T="03">e.g.,</E>
                     foreign studies) and information to support a request for accelerated approval. If such information has already been submitted to us, the information may be summarized in the premeeting package.  
                </P>
                <P>
                    The guidance documents are available on our website at 
                    <E T="03">www.fda.gov/regulatory-information/search-fda-guidance-documents</E>
                     and were issued consistent with our good guidance practice regulations in 21 CFR 10.115, which provide for public comment at any time.
                </P>
                <P>
                    We estimate the burden of this collection of information as follows:
                    <PRTPAGE P="1103"/>
                </P>
                <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s100,12,12,12,12,12">
                    <TTITLE>
                        Table 1—Estimated Annual Reporting Burden 
                        <SU>1</SU>
                    </TTITLE>
                    <BOXHD>
                        <CHED H="1">Activity</CHED>
                        <CHED H="1">
                            Number of
                            <LI>respondents</LI>
                        </CHED>
                        <CHED H="1">
                            Number of
                            <LI>responses per</LI>
                            <LI>respondent</LI>
                        </CHED>
                        <CHED H="1">
                            Total annual
                            <LI>responses</LI>
                        </CHED>
                        <CHED H="1">
                            Average
                            <LI>burden per</LI>
                            <LI>response</LI>
                        </CHED>
                        <CHED H="1">Total hours</CHED>
                    </BOXHD>
                    <ROW EXPSTB="05" RUL="s">
                        <ENT I="21">
                            <E T="02">CDER</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Priority Review Designation Requests (Expedited Programs for Serious Conditions Guidance (EPSC) Section VIII)</ENT>
                        <ENT>81</ENT>
                        <ENT>1.53</ENT>
                        <ENT>124</ENT>
                        <ENT>30</ENT>
                        <ENT>3,720</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Breakthrough Therapy Designation Requests (EPSC Section VI)</ENT>
                        <ENT>71</ENT>
                        <ENT>1.08</ENT>
                        <ENT>77</ENT>
                        <ENT>70</ENT>
                        <ENT>5,390</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fast Track Designation Requests (EPSC Section V)</ENT>
                        <ENT>235</ENT>
                        <ENT>1.18</ENT>
                        <ENT>277</ENT>
                        <ENT>60</ENT>
                        <ENT>16,620</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Accelerated Approval Designation (EPSC Section VII)</ENT>
                        <ENT>26</ENT>
                        <ENT>1.27</ENT>
                        <ENT>33</ENT>
                        <ENT>100</ENT>
                        <ENT>3,300</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="01">Premeeting Packages (21 CFR 312.82)</ENT>
                        <ENT>163</ENT>
                        <ENT>1.01</ENT>
                        <ENT>165</ENT>
                        <ENT>100</ENT>
                        <ENT>16,500</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="03">CDER Subtotal</ENT>
                        <ENT/>
                        <ENT/>
                        <ENT>676</ENT>
                        <ENT/>
                        <ENT>45,530</ENT>
                    </ROW>
                    <ROW EXPSTB="05" RUL="s">
                        <ENT I="21">
                            <E T="02">CBER</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Priority Review Designation Request (EPSC Section VIII)</ENT>
                        <ENT>8</ENT>
                        <ENT>1</ENT>
                        <ENT>8</ENT>
                        <ENT>30</ENT>
                        <ENT>240</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Breakthrough Therapy Designation Request (EPSC Section VI)</ENT>
                        <ENT>15</ENT>
                        <ENT>1.1</ENT>
                        <ENT>17</ENT>
                        <ENT>70</ENT>
                        <ENT>1,190</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Fast Track Designation Requests (EPSC Section VII)</ENT>
                        <ENT>64</ENT>
                        <ENT>1.2</ENT>
                        <ENT>77</ENT>
                        <ENT>60</ENT>
                        <ENT>4,620</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            RMAT Designation Requests (Regenerative Medicine Therapies for Serious Conditions Guidance (RMAT) Section III)
                            <LI>Guidance p 6)</LI>
                        </ENT>
                        <ENT>33</ENT>
                        <ENT>1.1</ENT>
                        <ENT>36</ENT>
                        <ENT>60</ENT>
                        <ENT>2,160</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="01">Premeeting Packages (RMAT Section V)</ENT>
                        <ENT>146</ENT>
                        <ENT>1.9</ENT>
                        <ENT>277</ENT>
                        <ENT>100</ENT>
                        <ENT>27,700</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">CBER Subtotal</ENT>
                        <ENT/>
                        <ENT/>
                        <ENT>415</ENT>
                        <ENT/>
                        <ENT>35,910</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="05">Total</ENT>
                        <ENT/>
                        <ENT/>
                        <ENT>1,091</ENT>
                        <ENT/>
                        <ENT>81,440</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         There are no capital costs or operating and maintenance costs associated with this collection of information.
                    </TNOTE>
                </GPOTABLE>
                <P>Based on FY 2022 receipts, we estimate that for Center for Drug Evaluation and Research (CDER) products, 81 respondents will submit 124 requests for priority review designation annually, and we assume 30 hours are needed to prepare such a request. We estimate 71 respondents will submit 77 requests for breakthrough designation annually, and we assume 70 hours are needed to prepare such a request. We estimate that 235 respondents will submit 277 requests for fast-track designation requests annually, and we assume 60 hours are required to prepare such a request. We estimate 26 respondents will submit 33 accelerated approval designation requests annually and we assume 100 hours are required to prepare such a request. Finally, CDER received 165 pre-meeting package submissions from 163 respondents. We assume 100 hours are needed to prepare a pre-meeting package.</P>
                <P>Similarly, also based on FY 2022 receipts, we estimate that for CBER products, 8 applicants will submit 8 requests for priority review designation annually, and we assume 30 hours are required to prepare such a request. We estimate 15 respondents will submit 17 requests for breakthrough designation annually, and we assume 70 hours are needed to prepare such a request. We estimate that 64 respondents will submit 78 requests for fast-track designation annually, and we assume 60 hours is required to prepare such a request. We also estimate 33 respondents will submit 35 requests for RMAT designation annually and assume that 60 hours are needed to prepare each RMAT designation request. Finally, CBER received 283 pre-meeting package submissions from 146 respondents. We assume 100 hours are needed to prepare a pre-meeting package.</P>
                <P>Based on a review of the information collection since our last request for OMB approval, we have increased our burden estimate by 143 responses and 10,350 hours to reflect actual submissions we have received. We attribute these changes to increased interest in the expedited programs, new expedited programs, and an increase in the number of submissions we received over the last few years.</P>
                <SIG>
                    <DATED>Dated: January 4, 2024.</DATED>
                    <NAME>Lauren K. Roth,</NAME>
                    <TITLE>Associate Commissioner for Policy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00217 Filed 1-8-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>Health Resources and Services Administration</SUBAGY>
                <SUBJECT>Agency Information Collection Activities: Proposed Collection: Public Comment Request; Information Collection Request Title: Bureau of Health Workforce Performance Data Collection, OMB No. 0915-0061—Revision</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Health Resources and Services Administration (HRSA), Department of Health and Human Services.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In compliance with the requirement for opportunity for public comment on proposed data collection projects of the Paperwork Reduction Act of 1995, HRSA announces plans to submit an Information Collection Request (ICR), described below, to the Office of Management and Budget (OMB). Prior to submitting the ICR to OMB, HRSA seeks comments from the public regarding the burden estimate, below, or any other aspect of the ICR.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments on this ICR should be received no later than February 8, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Written comments and recommendations for the proposed information collection should be sent 
                        <PRTPAGE P="1104"/>
                        within 30 days of publication of this notice to 
                        <E T="03">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.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        To request a copy of the clearance requests submitted to OMB for review, email Joella Roland, the HRSA Information Collection Clearance Officer, at 
                        <E T="03">paperwork@hrsa.gov</E>
                         or call (301) 443-3983.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>When submitting comments or requesting information, please include the information request collection title for reference.</P>
                <P>
                    <E T="03">Information Collection Request Title:</E>
                     Bureau of Health Workforce Performance Data Collection, OMB No. 0915-0061—Revision.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     Over 50 Bureau of Health Workforce (BHW) programs award grants to health professions schools and training programs across the United States to develop, expand, and enhance training, and to strengthen the distribution of the health workforce. These programs are governed by titles III, VII, and VIII of the Public Health Service Act. Performance information is collected in the HRSA Performance Report for Grants and Cooperative Agreements. Data collection activities consisting of an annual progress report and an annual performance report satisfy statutory and programmatic requirements for performance measurement and evaluation (including specific title III, VII and VIII requirements), as well as Government Performance and Results Act of 1993, the Government Performance and Results Act Modernization Act of 2010, and the Foundations for Evidence-Based Policymaking Act of 2018 requirements. The performance measures were last revised in 2022 to ensure they addressed programmatic changes, met evolving program management needs, and responded to emerging workforce concerns. As these changes were successful, BHW will continue with its current performance management strategy and make additional changes that reduce burden, simplify reporting, reflect new Department of Health and Human Services and HRSA priorities, and enable longitudinal analysis of program performance. Specifically, an Excel upload feature was implemented for all programs to reduce burden. Questions on partnerships were revised and standardized across forms to understand the type and purposes of partnerships associated with grant funding. Employment-related questions were standardized across programs and forms to provide consistent outcomes on employment location, type of employment, and hiring organization. New questions were added for programs using apprenticeships. Specifically, questions were added to measure additional employment outcomes including role at the employment site and vulnerable populations served and to measure program satisfaction and types of competencies graduates were ready to perform.
                </P>
                <P>
                    A 60-day notice published in the 
                    <E T="04">Federal Register</E>
                     on October 19, 2023, 88 FR 72086-87. There was one public comment. The commenter was complementary of BHW's efforts to consolidate performance data into one collection and raised questions related to collaborating with other departments on the data collection, defining apprenticeships, and making individual-level data publicly available. Specifically, the commenter asked how HRSA collaborates on data collection with agencies outside of the Department of Health and Human services. Our response to the commenter explained the data collected via this OMB package are performance metrics specific to HRSA grant programs and the data are used to meet obligations for performance budgeting. This is in alignment with the Government's authorization to collect data to meet reporting requirements. The commenter also asked how HRSA defines apprenticeships and how it aligns with definitions from other agencies. HRSA responded that it uses the Department of Labor's definition of apprentices and that it included questions from the Department of Labor's Employment and Training Administration instrument to reduce reporting burden and made data comparable across the agencies. Lastly, the commenter requested that HRSA make more individual-level data available, but statute prohibits HRSA from doing so (see 42 U.S.C. 292 
                    <E T="03">et seq.</E>
                    ). There was a follow-up comment from the same commenter regarding HRSA working with external researchers to analyze data on workforce program participants. HRSA's response was that HRSA does not work with external researchers to analyze data collected on workforce programs. Aggregated data is publicly available to external researchers via HRSA's data warehouse.
                </P>
                <P>
                    <E T="03">Need and Proposed Use of the Information:</E>
                     The purpose of the proposed data collection is to continue analysis and reporting of grantee training activities and education, identify details about the practice locations where trainees work (or plan to work) after program completion, and report outcomes of funded initiatives. Data collected from these grant programs will also provide a description of the program activities of approximately 1,828 reporting grantees to inform policymakers on the barriers, opportunities, and outcomes involved in health care workforce development. The proposed measures focus on four key outcomes:
                </P>
                <P>(1) increasing the workforce supply of well-educated practitioners in needed professions,</P>
                <P>(2) increasing the number of practitioners that practice in underserved and rural areas,</P>
                <P>(3) enhancing the quality of education, and</P>
                <P>(4) supporting educational infrastructure to increase the capacity to train more health professionals in high demand areas.</P>
                <P>
                    <E T="03">Likely Respondents:</E>
                     Respondents are awardees of BHW health professions grant programs.
                </P>
                <P>
                    <E T="03">Burden Statement:</E>
                     Burden in this context means the time expended by persons to generate, maintain, retain, disclose, or provide the information requested. This includes the time needed to review instructions; to develop, acquire, install, and utilize technology and systems for the purpose of collecting, validating and verifying information, processing and maintaining information, and disclosing and providing information; to train personnel and to be able to respond to a collection of information; to search data sources; to complete and review the collection of information; and to transmit or otherwise disclose the information. The total annual burden hours estimated for this ICR are summarized in the table below.
                    <PRTPAGE P="1105"/>
                </P>
                <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s25,12,12,12,12,12">
                    <TTITLE>Total Estimated Annualized Burden Hours</TTITLE>
                    <BOXHD>
                        <CHED H="1">Form name</CHED>
                        <CHED H="1">
                            Number of
                            <LI>respondents</LI>
                        </CHED>
                        <CHED H="1">
                            Number of
                            <LI>responses per</LI>
                            <LI>respondent</LI>
                        </CHED>
                        <CHED H="1">
                            Total
                            <LI>responses</LI>
                        </CHED>
                        <CHED H="1">
                            Average
                            <LI>burden per</LI>
                            <LI>response</LI>
                            <LI>(in hours)</LI>
                        </CHED>
                        <CHED H="1">
                            Total burden
                            <LI>hours</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Direct Financial Support Program</ENT>
                        <ENT>619</ENT>
                        <ENT>1</ENT>
                        <ENT>619</ENT>
                        <ENT>2.7</ENT>
                        <ENT>1,671.3</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Infrastructure Program</ENT>
                        <ENT>219</ENT>
                        <ENT>1</ENT>
                        <ENT>219</ENT>
                        <ENT>4.8</ENT>
                        <ENT>1,051.2</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="01">Multipurpose or Hybrid Program</ENT>
                        <ENT>1,044</ENT>
                        <ENT>1</ENT>
                        <ENT>1,044</ENT>
                        <ENT>3.1</ENT>
                        <ENT>3,236.4</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Total</ENT>
                        <ENT>1,882</ENT>
                        <ENT/>
                        <ENT>1,882</ENT>
                        <ENT/>
                        <ENT>5,958.9</ENT>
                    </ROW>
                </GPOTABLE>
                <P>HRSA specifically requests comments on: (1) the necessity and utility of the proposed information collection for the proper performance of the agency's functions; (2) the accuracy of the estimated burden; (3) ways to enhance the quality, utility, and clarity of the information to be collected; and (4) the use of automated collection techniques or other forms of information technology to minimize the information collection burden.</P>
                <SIG>
                    <NAME>Maria G. Button,</NAME>
                    <TITLE>Director, Executive Secretariat.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00210 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4165-15-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>Health Resources and Services Administration</SUBAGY>
                <SUBJECT>Meeting of the Advisory Committee on Heritable Disorders in Newborns and Children</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Health Resources and Services Administration (HRSA), Department of Health and Human Services.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        In accordance with section 1111(g) of the Public Health Service Act, and the Federal Advisory Committee Act, this notice announces that the Advisory Committee on Heritable Disorders in Newborns and Children (ACHDNC or Committee) has scheduled a public meeting. Information about the ACHDNC and the agenda for this meeting can be found on the ACHDNC website at 
                        <E T="03">https://www.hrsa.gov/advisory-committees/heritable-disorders/index.html.</E>
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Monday, January 29, 2024, from 10 a.m. to 5 p.m. Eastern Time (ET) and Tuesday, January 30, 2024, from 10 a.m. to 3 p.m. ET.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        This meeting will be held in person with webcast options. While this meeting is open to the public, advance registration is required. Please visit the ACHDNC website for information on registration, 
                        <E T="03">https://www.hrsa.gov/advisory-committees/heritable-disorders/index.html,</E>
                         by the deadline of 12 p.m. ET on Friday, January 26, 2024. Instructions on how to access the meeting via webcast will be provided upon registration. If you are a non-United States citizen who would like to attend the January meeting in-person, please contact 
                        <E T="03">ACHDNC@hrsa.gov</E>
                         by January 11, 2024.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Kim Morrison, Maternal and Child Health Bureau, HRSA, 5600 Fishers Lane, Room, Rockville, Maryland 20857; 301-822-4978; or 
                        <E T="03">ACHDNC@hrsa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    ACHDNC provides advice and recommendations to the Secretary of Health and Human Services (Secretary) on the development of newborn screening activities, technologies, policies, guidelines, and programs for effectively reducing morbidity and mortality in newborns and children having, or at risk for, heritable disorders. ACHDNC reviews and reports regularly on newborn and childhood screening practices, recommends improvements in the national newborn and childhood screening programs, and fulfills requirements stated in the authorizing legislation. In addition, ACHDNC's recommendations regarding inclusion of additional conditions for screening on the Recommended Uniform Screening Panel (RUSP), following adoption by the Secretary, are evidence-informed preventive health services provided for in the comprehensive guidelines supported by HRSA pursuant to section 2713 of the Public Health Service Act (42 U.S.C. 300gg-13). Under this provision, non-grandfathered group health plans and health insurance issuers offering non-grandfathered group or individual health insurance are required to provide insurance coverage without cost-sharing (a co-payment, co-insurance, or deductible) for preventive services for plan years (
                    <E T="03">i.e.,</E>
                     policy years) beginning on or after the date that is one year from the Secretary's adoption of the condition for screening.
                </P>
                <P>During the January 29-30, 2024, meeting, ACHDNC will hear from experts in the fields of public health, medicine, heritable disorders, rare disorders, and newborn screening. Agenda items include the following topics:</P>
                <P>(1) A possible presentation on qualitative research that focuses on family perspectives;</P>
                <P>(2) Updates from Committee ad hoc topic groups. Potential topics include: the nomination process and revisions to the decision matrix;</P>
                <P>(3) An update on the evidence review of Duchenne muscular dystrophy nomination; and</P>
                <P>(4) Presentation of the final evidence-based review report on the Krabbe disease condition nomination for possible inclusion on the RUSP. Following this report presentation, the ACHDNC expects to vote on the second meeting day, on January 30, 2024, whether to recommend to the Secretary adding Krabbe disease to the RUSP (with potential implications under section 2713 of the Public Health Service Act, as noted above).</P>
                <P>The agenda for this meeting includes a potential vote to recommend a nominated condition (Krabbe disease) be added by the Secretary to the RUSP. Agenda items are subject to change as priorities dictate. Information about the ACHDNC, including a roster of members and past meeting summaries, is also available on the ACHDNC website.</P>
                <P>
                    Members of the public also will have the opportunity to provide comments on any or all of the above agenda items. Public participants may request to provide general oral comments and may submit written statements in advance of the scheduled meeting. Oral comments will be honored in the order they are requested and may be limited as time allows. Subject to change: members of the public registered to submit oral public comments on Krabbe disease are tentatively scheduled to provide their statements on Tuesday, January 30, 2024. Members of the public registered to provide oral public comments on all other newborn screening related topics are tentatively scheduled to provide 
                    <PRTPAGE P="1106"/>
                    their statements on Monday, January 29, 2024. Requests to provide a written statement or make oral comments to ACHDNC must be submitted via the registration website by 12 p.m. ET on Tuesday, January 17, 2024. Written comments will be shared with the Committee prior to the meeting so that they have an opportunity to consider them in advance of the meeting. Individuals who need special assistance or another reasonable accommodation should notify Kim Morrison at the address and phone number listed above at least 10 business days prior to the meeting.
                </P>
                <P>Since this meeting occurs in a federal government building, attendees must go through a security check to enter the building. Non-United States Citizen attendees must notify HRSA of their planned attendance at least 15 business days prior to the meeting in order to facilitate their entry into the building. All attendees are required to present government-issued identification prior to entry.</P>
                <SIG>
                    <NAME>Maria G. Button,</NAME>
                    <TITLE>Director, Executive Secretariat.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00264 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4165-15-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>National Institutes of Health</SUBAGY>
                <SUBJECT>National Eye Institute; 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 Eye Institute Special Emphasis Panel; Center Core Grant for Vision Research (P30).
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         February 20, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         11:00 a.m. to 3:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Eye Institute, 6700B Rockledge Drive, Bethesda, MD 20817 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Brian Hoshaw, Ph.D., Designated Federal Official, Division of Extramural Research, National Eye Institute, National Institutes of Health, 6700 B Rockledge Dr.,  Rockville, MD 20892, 301-451-2020, 
                        <E T="03">hoshawb@mail.nih.gov.</E>
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         National Eye Institute Special Emphasis Panel; Clinical Applications.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         February 27, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         11:00 a.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 Eye Institute, 6700 Rockledge Drive, Bethesda, MD 20817 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Ashley Fortress, Ph.D., Designated Federal Official, Division of Extramural Activities, National Eye Institute, National Institutes of Health, 6700 B Rockledge Dr., Bethesda, MD 20817, (301) 451-2020 
                        <E T="03">ashley.fortress@nih.gov.</E>
                    </P>
                    <FP>(Catalogue of Federal Domestic Assistance Program No. 93.867, Vision Research, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: January 4, 2024.</DATED>
                    <NAME>Victoria E. Townsend, </NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00212 Filed 1-8-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 Mental Health; 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 of Mental Health Special Emphasis Panel; Measures to Advance Quality in Mental Health Services.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         February 6, 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, Neuroscience Center, 6001 Executive Boulevard, Rockville, MD 20852 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Serena Chu, Ph.D., Scientific Review Officer, Division of Extramural Activities, National Institute of Mental Health, National Institutes of Health, Neuroscience Center, 6001 Executive Blvd. Bethesda, MD 20852, 301-500-5829, 
                        <E T="03">serena.chu@nih.gov.</E>
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         National Institute of Mental Health Special Emphasis Panel; Non-Pharmacological Clinical Trials.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         February 8, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         11: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, Neuroscience Center, 6001 Executive Boulevard, Rockville, MD 20852 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Serena Chu, Ph.D., Scientific Review Officer, Division of Extramural Activities, National Institute of Mental Health, National Institutes of Health, Neuroscience Center, 6001 Executive Blvd., Bethesda, MD 20852, 301-500-5829, 
                        <E T="03">serena.chu@nih.gov.</E>
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         National Institute of Mental Health Special Emphasis Panel; BRAIN Initiative: Research on the Ethical Implications of Advancements in Neurotechnology and Brain Science (R01).
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         February 9, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         12:00 p.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, Neuroscience Center, 6001 Executive Boulevard, Rockville, MD 20852 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Rebecca Steiner Garcia, Ph.D., Scientific Review Officer, Division of Extramural Activities, National Institute of Mental Health, National Institutes of Health, Neuroscience Center, 6001 Executive Blvd., Bethesda, MD 20892-9608, 301-443-4525, 
                        <E T="03">steinerr@mail.nih.gov.</E>
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         National Institute of Mental Health Special Emphasis Panel; Early Phase Clinical Trials: Pharma/Device and K Awards.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         February 22, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         1:00 p.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, Neuroscience Center, 6001 Executive Boulevard, Rockville, MD 20852 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Regina Dolan-Sewell, Ph.D., Scientific Review Officer, Division of Extramural Activities, National Institute of Mental Health, National Institutes of Health, Neuroscience Center, 6001 Executive Blvd., Bethesda, MD 20852, (240) 796-6785, 
                        <E T="03">regina.dolan-sewell@nih.gov.</E>
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         National Institute of Mental Health Special Emphasis Panel; BRAIN R01.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         February 28, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         11:00 a.m. to 6:30 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, Neuroscience Center, 6001 Executive Boulevard Rockville, MD 20852, (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         EMMA Perez-Costas, Ph.D., Scientific Review Officer, Division of Extramural Activities, National Institute of Mental Health, National Institutes of Health, 
                        <PRTPAGE P="1107"/>
                        6001 Executive Blvd., Rockville, MD 20892, (240) 936-6720, 
                        <E T="03">emma.perez-costas@nih.gov.</E>
                    </P>
                    <FP>(Catalogue of Federal Domestic Assistance Program No. 93.242, Mental Health Research Grants, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: January 4, 2024. </DATED>
                    <NAME>Lauren A. Fleck, </NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00248 Filed 1-8-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 Minority Health and Health Disparities; 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 Institute on Minority Health and Health Disparities Special Emphasis Panel; NIMHD Support for Conferences and Scientific Meetings (R13).
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         February 13, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         1:00 p.m. to 3: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, NIMHD DEM II, Suite 800, 6707 Democracy Boulevard, Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Jingsheng Tuo, Ph.D., Scientific Review Officer, Office of Extramural Research Administration, National Institute on Minority Health and Health Disparities, National Institutes of Health, 6707 Democracy Blvd., Suite 800, Bethesda, MD 20892, (301) 451-5953, 
                        <E T="03">jingsheng.tuo@nih.gov</E>
                        .
                    </P>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: January 4, 2024.</DATED>
                    <NAME>Victoria E. Townsend, </NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00211 Filed 1-8-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 Allergy and Infectious Diseases; 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 of Allergy and Infectious Diseases Special Emphasis Panel; NIAID SPF Macaque Breeding Colonies.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         February 7, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         8:00 a.m. to 6:30 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate contract proposals.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institute of Allergy and Infectious Diseases, National Institutes of Health, 5601 Fishers Lane, Room 3G53, Rockville, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Konrad Krzewski, Ph.D., Scientific Review Officer, Scientific Review Program, Division of Extramural Activities,  National Institute of Allergy and Infectious Diseases, National Institutes of Health, 5601 Fishers Lane, Room 3G53, Rockville, MD 20852, 240-747-7526, 
                        <E T="03">konrad.krzewski@nih.gov</E>
                        .
                    </P>
                    <FP>(Catalogue of Federal Domestic Assistance Program Nos. 93.855, Allergy, Immunology, and Transplantation Research; 93.856, Microbiology and Infectious Diseases Research, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: January 3, 2024.</DATED>
                    <NAME>Lauren A. Fleck, </NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00201 Filed 1-8-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>Prospective Grant of an Exclusive Patent License: Development and Commercialization of Thermally Responsive T Cell Therapies for the Treatment of HPV-Positive Cancer(s)</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Institutes of Health, HHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The National Cancer Institute, an institute of the National Institutes of Health, Department of Health and Human Services, is contemplating the grant of an Exclusive Patent License to practice the inventions embodied in the Patents and Patent Applications listed in the Supplementary Information section of this Notice to Port Therapeutics, Inc. (“Port”). Port incorporated in Delaware and is presently headquartered in Los Angeles, California.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Only written comments and/or applications for a license which are received by the National Cancer Institute's Technology Transfer Center on or before January 24, 2024 will be considered.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Requests for copies of the patent applications, inquiries, and comments relating to the contemplated Exclusive Patent License should be directed to: Andrew Burke, Ph.D., Senior Technology Transfer Manager, NCI Technology Transfer Center, Telephone: (240) 276-5484; Email: 
                        <E T="03">andy.burke@nih.gov.</E>
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Intellectual Property</HD>
                <EXTRACT>
                    <P>1. United States Provisional Patent Application No. 62/004,335 filed May 29, 2014, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-US-01];</P>
                    <P>2. PCT Patent Application No. PCT/US2015/033129 filed May 29, 2015, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-PCT-02];</P>
                    <P>3. Australian Patent No. 2015266818 issued January 16, 2020, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-AU-03];</P>
                    <P>4. Brazilian Patent Application No. BR112016027805-4 effective filing date of May 29, 2015, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-BR-04];</P>
                    <P>5. Canadian Patent Application No. 2,950,192 effective filing date of May 29, 2015, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-CA-05];</P>
                    <P>6. Chinese Patent No. ZL201580031789.X issued May 4, 2021, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-CN-06];</P>
                    <P>7. European Patent No. 3149031 issued December 18, 2019, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-EP-07];</P>
                    <P>a. Validated in: AL, AT, BE, BG, CH, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HR, HU, IE, IS, IT, LT, LU, LV, MK, MT, NL, NO, PL, PT, RO, SE, SI, SK, SM and TR.</P>
                    <P>
                        8. Israeli Patent No. 248797 issued September 1, 2021, entitled “Anti-Human 
                        <PRTPAGE P="1108"/>
                        Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-IL-08];
                    </P>
                    <P>9. Japanese Patent No. 6742991 issued August 19, 2020, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-JP-09];</P>
                    <P>10. Korean Patent No. 10-2445667 issued September 16, 2022, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-KR-10];</P>
                    <P>11. Mexican Patent No. 375379 issued September 25, 2020, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-MX-11];</P>
                    <P>12. Saudi Arabian Patent No. 7456 issued January 5, 2021, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-SA-12];</P>
                    <P>13. United States Patent No. 10,174,098 issued January 8, 2019, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-US-13];</P>
                    <P>14. Hong Kong Patent No. HK1236203 issued January 8, 2021, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-HK-14];</P>
                    <P>15. United States Patent No. 10,870,687 issued December 22, 2020, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-US-15];</P>
                    <P>16. European Patent Application No. 19217074.4 filed December 17, 2019, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-EP-16];</P>
                    <P>17. Australian Patent No. 2019283892 issued May 13, 2021, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-AU-17];</P>
                    <P>18. Japanese Patent No. 6997267 issued December 20, 2021, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-JP-53];</P>
                    <P>19. Saudi Arabian Patent Application No. 520412601 filed August 10, 2020, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-SA-54];</P>
                    <P>20. Hong Kong Patent Application No. 42020020661.3 filed November 24, 2020, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-HK-55];</P>
                    <P>21. Mexican Patent Application No. MX/a/2020/010035 filed September 24, 2020, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-MX-56];</P>
                    <P>22. United States Patent No. 11,434,272 issued September 6, 2020, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-US-57];</P>
                    <P>23. Australian Patent No. 2021202227 issued February 23, 2023, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-AU-58];</P>
                    <P>24. Chinese Patent Application No. 20210399056.9 filed April 14, 2021, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-CN-59];</P>
                    <P>25. Israeli Patent No. 282518 issued July 2, 2022, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-IL-60];</P>
                    <P>26. Hong Kong Patent Application No. 42022046605.6 filed January 19, 2022, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-HK-62];</P>
                    <P>27. Japanese Patent No. 7291196 issued June 6, 2023, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-JP-63];</P>
                    <P>28. Israeli Patent Application No. 290655 filed February 16, 2022, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-IL-64];</P>
                    <P>29. United States Patent Application No. 17/816,496 filed August 1, 2022, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-US-65];</P>
                    <P>30. Korean Patent Application No. 2022-7032043 filed September 15, 2022, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-KR-66];</P>
                    <P>31. Australian Patent Application No. 2023200608 filed February 6, 2023, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-AU-01]; and</P>
                    <P>32. Japanese Patent Application No. 2023-091878 filed June 2, 2023, entitled “Anti-Human Papillomavirus 16 E7 T Cell Receptors” [HHS Reference No. E-176-2014-0-JP-01].</P>
                </EXTRACT>
                <P>The patent rights in these inventions have been assigned and/or exclusively licensed to the government of the United States of America.</P>
                <P>The prospective exclusive license territory may be worldwide, and the field of use may be limited to the following:</P>
                <P>“Thermally controlled autologous T cell therapy products for the treatment of HPV-positive cancer in humans.”</P>
                <P>The E-176-2014 patent family is primarily directed to an isolated TCR reactive to HPV 16 E7 antigen in the context of HLA-A*02:01 (the “E7 TCR”). HPV describes a group of human viruses known to cause malignancy. Of the group, HPV-16 is the most prevalent strain. Approximately 90% of adults are estimated to have been exposed at some point in their lifetime. HPV drives transformation of infected cells through the expression of certain oncoproteins, chiefly E5, E6 and E7. The latter two are constitutively expressed in malignant cells and are necessary to maintain a transformed state, rendering them attractive therapeutic targets.</P>
                <P>
                    The E7 TCR may be useful in the development of certain diagnostics and/or therapeutics for the treatment of cancers which express both the HPV 16 E7 oncoprotein and HLA-A*02:01. Potential therapeutic applications of the E7 TCR may include, but are not limited to, engineered autologous or allogeneic immune cell therapies (
                    <E T="03">e.g.,</E>
                     T cell or natural killer cell-based) and TCR fusion proteins and conjugates (
                    <E T="03">e.g.,</E>
                     soluble TCR bi-specifics or TCR-drug conjugates). The exclusive field of use which may be granted to Port applies to “thermally controlled” autologous T cell products, which is a subset of engineered immune cell therapies.
                </P>
                <P>This Notice is made in accordance with 35 U.S.C. 209 and 37 CFR part 404. The prospective exclusive license will be royalty bearing, and the prospective exclusive license may be granted unless within fifteen (15) days from the date of this published Notice, the National Cancer Institute receives written evidence and argument that establishes that the grant of the license would not be consistent with the requirements of 35 U.S.C. 209 and 37 CFR part 404.</P>
                <P>In response to this Notice, the public may file comments or objections. Comments and objections, other than those in the form of a license application, will not be treated confidentially and may be made publicly available.</P>
                <P>License applications submitted in response to this Notice will be presumed to contain business confidential information and any release of information from these license applications will be made only as required and upon a request under the Freedom of Information Act, 5 U.S.C. 552.</P>
                <SIG>
                    <DATED>Dated: January 4, 2024.</DATED>
                    <NAME>Richard U. Rodriguez,</NAME>
                    <TITLE>Associate Director, Technology Transfer Center, National Cancer Institute.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00209 Filed 1-8-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>Office of the Director, National Institutes of Health; 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 Council of Councils.</P>
                <P>
                    The meeting will be held as a virtual meeting open to the public as indicated below, with attendance limited to space available. Individuals who plan to attend as well as those who need special assistance, such as sign language interpretation or other reasonable accommodations, must notify the Contact Person listed below in advance of the meeting. The open session will be 
                    <PRTPAGE P="1109"/>
                    videocast and can be accessed from the NIH Videocasting and Podcasting website (
                    <E T="03">http://videocast.nih.gov/</E>
                    ).
                </P>
                <P>A portion of 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/or 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 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>
                         Council of Councils.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         January 25-26, 2024.
                    </P>
                    <P>
                        <E T="03">Open:</E>
                         January 25, 2024, 10:00 a.m. to 3:45 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         Welcome and Opening Remarks; Announcements; NIH Program Updates; Strategic Plans; and Other Business of the Committee.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, Building 1, 1 Center Drive, Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Closed:</E>
                         January 25, 2024, 4:00 p.m. to 5:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         Review of Grant Applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, Building 1, 1 Center Drive, Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Open:</E>
                         January 26, 2024, 10:15 a.m. to 3:15 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         Strategic Plans; and Other Business of the Committee.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, Building 1, 1 Center Drive, Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Franziska Grieder, D.V.M., Ph.D., Executive Secretary, Council of Councils, Director, Office of Research Infrastructure Programs, Division of Program Coordination, Planning, and Strategic Initiatives, Office of the Director, NIH, 6701 Democracy Boulevard, Room 948, Bethesda, MD 20892, 
                        <E T="03">GriederF@mail.nih.gov</E>
                        , 301-435-0744.
                    </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>
                        Information is also available on the Council of Council's home page at 
                        <E T="03">http://dpcpsi.nih.gov/council/</E>
                         where an agenda will be posted before the meeting date.
                    </P>
                    <FP>(Catalogue of Federal Domestic Assistance Program Nos. 93.14, Intramural Research Training Award; 93.22, Clinical Research Loan Repayment Program for Individuals from Disadvantaged Backgrounds; 93.232, Loan Repayment Program for Research Generally; 93.39, Academic Research Enhancement Award; 93.936, NIH Acquired Immunodeficiency Syndrome Research Loan Repayment Program; 93.187, Undergraduate Scholarship Program for Individuals from Disadvantaged Backgrounds, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: January 4, 2024.</DATED>
                    <NAME>David W. Freeman,</NAME>
                    <TITLE>Supervisory Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00247 Filed 1-8-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 Allergy and Infectious Diseases; 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 of Allergy and Infectious Diseases Special Emphasis Panel; HHS-NIH-CDC-SBIR PHS 2024-1 Phase I: Development of a Serological Test for Herpes Simplex Types 1 and 2 Infections (Topic 133).
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         February 6, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         10:00 a.m. to 3: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 of Allergy and Infectious Diseases, National Institutes of Health, 5601 Fishers Lane, Room 3F52A, Rockville, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Shilpakala Ketha, Ph.D., Scientific Review Officer, Scientific Review Program, Division of Extramural Activities, National Institute of Allergy and Infectious Diseases, National Institutes of Health, 5601 Fishers Lane, Room 3F52A, Rockville, MD 20852, (301) 761-6821, 
                        <E T="03">shilpa.ketha@nih.gov</E>
                        .
                    </P>
                    <FP>(Catalogue of Federal Domestic Assistance Program Nos. 93.855, Allergy, Immunology, and Transplantation Research; 93.856, Microbiology and Infectious Diseases Research, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: January 3, 2024. </DATED>
                    <NAME>Lauren A. Fleck, </NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00200 Filed 1-8-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 Biomedical Imaging and Bioengineering; 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 meetings of the National Institute of Biomedical Imaging and Bioengineering Special Emphasis Panel.</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 of Biomedical Imaging and Bioengineering Special Emphasis Panel; Career Development (Ks) and Conference support (R13) Review.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         February 22, 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, Dem II, Suite 920, 6707 Democracy Boulevard, Bethesda, MD 20817 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Tianhong Wang, MD, Ph.D., Scientific Review Officer, National Institute of Biomedical Imaging and Bioengineering, National Institutes of Health, 6707 Democracy Blvd., Bethesda, MD 20892, (301) 435-1189, 
                        <E T="03">wangt3@mail.nih.gov.</E>
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         National Institute of Biomedical Imaging and Bioengineering Special Emphasis Panel; P41 NCBIB Review D-SEP.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         March 20-22, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         9:30 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, Dem II, Suite 920, 6707 Democracy Blvd., Bethesda, MD 20817 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         John K. Hayes, Ph.D., Scientific Review Officer, National Institute of Biomedical Imaging and Bioengineering, National Institutes of Health, 6707 Democracy Blvd., Suite 959, Bethesda, MD 20892, (301) 451-3398, 
                        <E T="03">hayesj@mail.nih.gov.</E>
                    </P>
                    <FP>(Catalogue of Federal Domestic Assistance Program Nos. 93.866, National Institute of Biomedical Imaging and Bioengineering, National Institutes of Health.)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: January 4, 2024.</DATED>
                    <NAME>Victoria E. Townsend,</NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00208 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4140-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="1110"/>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>National Institutes of Health</SUBAGY>
                <SUBJECT>National Institute of Dental &amp; Craniofacial Research; 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 Institute of Dental and Craniofacial Research; Special Grants Review Committee.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         February 22-23, 2024.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         9:00 a.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 Institute of Dental &amp; Craniofacial Research, 6701 Democracy Blvd., Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Thomas John O'Farrell, Ph.D., Scientific Review Officer, Scientific Review Branch, Division of Extramural Activities, National Institute of Dental &amp; Craniofacial Research, 6701 Democracy Blvd., Bethesda, MD 20892, 301-402-8559, 
                        <E T="03">tom.ofarrell@nih.gov</E>
                        .
                    </P>
                    <FP>(Catalogue of Federal Domestic Assistance Program No. 93.121, Oral Diseases and Disorders Research, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: January 4, 2024.</DATED>
                    <NAME>Lauren A. Fleck,</NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00249 Filed 1-8-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>
                <SUBJECT>Solicitation for Public Comments on Questions From the Task Force on Maternal Mental Health</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office on Women's Health, Office of the Assistant Secretary for Health, Office of the Secretary; Substance Abuse and Mental Health Services Administration (SAMHSA), U.S. Department of Health and Human Services (HHS)</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of request for information</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Task Force on Maternal Mental Health (Task Force), which is being implemented as a subcommittee of the SAMHSA Advisory Committee for Women's Services (ACWS), solicits public comments on a set of questions concerning the context, policies, effectiveness, promising practices, and limitations and gaps related to prevention and treatment of maternal mental health conditions and substance use disorders (inclusive of alcohol use/misuse) and its complications. The Task Force is required to solicit public comments, as appropriate, from stakeholders for the purposes of developing a report that analyzes and evaluates the state of maternal mental health programs at the Federal level and identifies best practices with respect to maternal mental health and substance use disorders as well as a national strategy for improving maternal mental health. The taskforce will be highlighting recommendations that fall within the pregnancy and postpartum (up to 1 year after birth) periods for individuals with or at risk for mental health and substance use conditions.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Electronic or written/paper comments will be accepted through midnight eastern standard time (EST) January 31, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The set of questions is available in the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section below. Public comments can be submitted in the following ways:
                    </P>
                    <P>
                        • Electronic submissions can be filed online at 
                        <E T="03">http://www.regulations.gov</E>
                         by following the “Instructions for Public Comments” section below. Comments submitted electronically, including attachments, will be posted to the docket unchanged. Evidence and information supporting your comment can be submitted as attachments. Please provide your contact information or organization name on the web-based form for follow up by the Task Force.
                    </P>
                    <P>
                        • If you prefer to comment on paper, mail your comment to the following address: 5600 Fishers Lane, Suite 18E01, Rockville, MD 20857. For mailed submissions, OWH/SAMHSA will post your comment, as well as any attachments, to 
                        <E T="03">http://www.regulations.gov.</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 ID into the “Search” box and follow the prompts.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Valerie Kolick, Designated Federal Officer, Advisory Committee for Women's Services, U.S. Department of Health and Human Services, Substance Abuse and Mental Health Services Administration, 5600 Fishers Lane, Suite 18E01, Rockville, MD 20857. Phone: 240-276-1738 or Email: 
                        <E T="03">valerie.kolick@samhsa.hhs.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Section 1113 of the Consolidated Appropriations Act, 2023 (Pub. L. 117-328) requires the HHS Secretary to establish a Task Force on Maternal Mental Health or incorporate the duties, public meetings, and reports specified into existing relevant Federal committees or working groups. The Task Force consists of representatives of specific federal agencies and non-federal individuals and entities who represent diverse disciplines and views. The Task Force will evaluate and make recommendations to the ACWS for further deliberation regarding improvements and coordination for Federal activities that address maternal mental health and co-occurring substance use disorders. The ACWS will make final recommendations to the Secretary of Health and Human Services and to Congress.</P>
                <P>The Task Force invites members of the public to comment on any issues or concerns they believe are relevant or appropriate to the state of maternal mental health programs at the Federal level, and identification of best practices with respect to maternal mental health and substance use. Specifically, the Task Force requests public comment on the following questions:</P>
                <P>1. Data, Research and Quality Improvement:</P>
                <P>• What are the priority outcomes for pregnant and postpartum individuals with substance use disorder and/or mental health conditions?</P>
                <P>• How would you define quality care for pregnant and postpartum individuals with substance use disorders and/or mental health conditions?</P>
                <P>• What are the priority research questions and gaps related to maternal substance use disorder and/or mental health conditions that must be addressed to improve services and outcomes for individuals while pregnant and postpartum?</P>
                <P>2. Prevention, Screening and Diagnosis:</P>
                <P>• What is lacking and what is working to support maternal emotional health, and substance use and well-being during pregnancy and after?</P>
                <P>
                    • What steps should be taken to ensure that approaches to detecting maternal emotional health issues and substance use challenges are culturally appropriate?
                    <PRTPAGE P="1111"/>
                </P>
                <P>• What can be done to help pregnant and postpartum individuals feel more comfortable to open up about how they are feeling? Who, where, and how might pregnant and postpartum individuals feel safest about disclosing their experience?</P>
                <P>3. Evidence-based Intervention and Treatment:</P>
                <P>• What are key evidence-based intervention and treatment models that should be broadly implemented to address maternal mental health and substance use?</P>
                <P>i. Do providers have the training and resources to appropriately provide evidenced-based intervention and treatment or referral?</P>
                <P>ii. Are community-based resources being utilized to bridge the gap in education, evidence-based screening, and treatment or referral? If not, what are the challenges of incorporating culturally competent community-based health care workers?</P>
                <P>• What are the barriers/gaps to evidence-based intervention for maternal mental health and substance use among reproductive age individuals? How do access and engagement differ between people who have already received mental health and/or substance use treatment prior to pregnancy versus those who never have?</P>
                <P>• Are underserved populations represented in the research and subsequent guidelines developed from the research for screening and treatment? What evidence is still needed to inform guidelines for screening and treatment, including for underrepresented, underserved populations?</P>
                <P>i. Underserved populations may include Black, Latino, and Indigenous and American Indian/Alaska Native persons, Asian Americans and Pacific Islanders and other persons of color; members of religious minorities; lesbian, gay, bisexual, transgender, queer, and intersex (LGBTQI+) persons; persons with disabilities; persons who live in rural areas; and persons otherwise adversely affected by persistent poverty or inequality.</P>
                <P>4. Evidence-Based Community Practices:</P>
                <P>
                    • What are the most pressing needs related to maternal mental health and maternal substance use in your community? For the purposes of this question, please define “community” however it most resonates with you (
                    <E T="03">e.g.,</E>
                     geography, race, ethnicity, sexual orientation, and gender identity, disability status, American Indian/Alaska Native status, veteran status, etc.)
                </P>
                <P>• What strategies have been the most successful, transformative, and/or sustainable in addressing maternal mental health and maternal substance use needs in your community? What strategies have been the least successful, transformative, and/or sustainable, and why?</P>
                <P>
                    • What innovations are needed to better address maternal mental health and substance use needs in your community (
                    <E T="03">i.e.,</E>
                     how can community-based organizations and entrepreneurs partner to address gaps and provide support for areas of identified need)?
                </P>
                <P>5. Communications and Community Engagement:</P>
                <P>• What do ideal services and resources look like for a pregnant or postpartum individual in your community? And what are barriers to access to these services?</P>
                <P>• What steps should be taken to ensure that approaches to detecting maternal emotional health issues and substance use challenges are culturally appropriate?</P>
                <P>• What can be done to help mothers and pregnant and postpartum people feel more comfortable to open up about how they are feeling? Who, where, and how might mothers and pregnant and postpartum people feel safest about disclosing their experience?</P>
                <P>
                    <E T="03">How to submit a response:</E>
                     All submissions must be submitted in the Docket ID HHS- for “Solicitation for Public Comments on Questions from the Task Force on Maternal Mental Health.” Comments are encouraged from the public and will be accepted through January 31, 2024. The 
                    <E T="03">https://www.regulations.gov</E>
                     electronic filing system will accept electronic comments until midnight eastern time at the end of January 31, 2024. Comments received by mail/courier will be considered if they are postmarked or the delivery service acceptance receipt date is on or before that date. Written comments via mail will be uploaded into 
                    <E T="03">https://www.regulations.gov</E>
                     and are under the same limitations as for those directly submitted electronically into 
                    <E T="03">https://www.regulations.gov:</E>
                     5,000 character limit for text box, and maximum number (10) of attached files and maximum size (10 MB) of each attached file.
                </P>
                <P>This RFI is for informational and planning purposes only and is not a solicitation for applications or an obligation on the part of the Government to provide support for any ideas identified in response to it. Please note that the Government will not pay for the preparation of any information submitted or for use of that information.</P>
                <SIG>
                    <NAME>Alicia Broadus,</NAME>
                    <TITLE>Public Health Advisor.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2023-28890 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4162-20-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Coast Guard</SUBAGY>
                <DEPDOC>[Docket No. USCG-2023-0674]</DEPDOC>
                <SUBJECT>National Maritime Security Advisory Committee; February 2024 Meeting</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>United States Coast Guard (USCG), Department of Homeland Security (DHS).</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 National Maritime Security Advisory Committee (Committee) will conduct a series of meetings over three days in conjunction with the 11th Annual Maritime Security East Conference in Arlington, VA to discuss the Committee's open taskings concerning NVIC 03-03 updates, Active Shooter/Active Threat in the Maritime Environment, and Unmanned Systems in the Maritime Environment. All meetings will be open to the public and will not require registration to the Conference.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P/>
                    <P>
                        <E T="03">Meetings:</E>
                         The Committee will meet on Monday, February 5, 2024, from 1:40 p.m. until 3:40 p.m. Eastern Standard Time (EST), Tuesday, February 6, 2024, from 10 a.m. until noon (EST), and on Wednesday, February 7, 2024, from 10:15 a.m. until 12:15 p.m. (EST). Please note these meetings may close early if the Committee has completed its business.
                    </P>
                    <P>
                        <E T="03">Comments and supporting documentation:</E>
                         To ensure your comments are received by Committee members before the meetings, submit your written comments no later than February 1, 2024.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The meetings will be held in the Tidewater II conference room at the Hyatt Regency Crystal City, 2799 Richmond Highway, Arlington, VA 22202, website Crystal City, VA Hotels Near DCA | Hyatt Regency Crystal City at Reagan National Airport. The meetings will also be held virtually. To join the virtual meetings or to request special accommodations, contact the individual listed in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section no later than 1 p.m. EST on February 1, 2024, to 
                        <PRTPAGE P="1112"/>
                        obtain the needed information. The number of virtual lines are limited and will be available on a first-come, first-served basis.
                    </P>
                    <P>
                        <E T="03">Pre-Registration Information:</E>
                         Pre-registration is required for attending the virtual meeting. You must request attendance by contacting the individual listed in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section below. You will receive a response with attendance instructions.
                    </P>
                    <P>
                        The National Maritime Security Advisory Committee is committed to ensuring all participants have equal access regardless of disability status. If you require reasonable accommodations due to a disability to fully participate, please email Mr. Ryan Owens at 
                        <E T="03">ryan.f.owens.uscg.mil</E>
                         or call (202) 302-6565 as soon as possible.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         You are free to submit comments at any time, including orally at the meeting as time permits. But, if you want Committee members to review your comment before the meetings, please submit your comments no later than February 1, 2024. We are particularly interested in comments on the topics in the “Agenda” section below. We encourage you to submit comments through the Federal Decision Making Portal at 
                        <E T="03">https://www.regulations.gov.</E>
                         To do so, go to 
                        <E T="03">https://www.regulations.gov,</E>
                         type USCG-2023-0674 in the search box and click “Search”. Next, look for this document in the Search Results column, and click on it. Then click on the Comment option. If your material cannot be submitted using 
                        <E T="03">https://www.regulations.gov,</E>
                         contact the individual in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section for alternate instructions. You must include the docket number USCG-2023-0674. Comments received will be posted without alteration at 
                        <E T="03">https://www.regulations.gov</E>
                         including any personal information provided. You may wish to review the Privacy and Security Notice found via a link on the homepage 
                        <E T="03">https://www.regulations.gov.</E>
                         For more about the privacy and submissions in response to this document, see DHS's eRulemaking System of Records notice (85 FR 14226, March 11, 2020). If you encounter technical difficulties with comment submission, contact the individual listed in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section of this notice.
                    </P>
                    <P>
                        <E T="03">Docket Search:</E>
                         Documents mentioned in this notice as being available in the docket, and all public comments, will be in our online docket at 
                        <E T="03">https://www.regulations.gov,</E>
                         and can be viewed by following that website's instructions. Additionally, if you go to the online docket and sign-up for email alerts, you will be notified when comments are posted.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Mr. Ryan Owens, Alternate Designated Federal Officer of the National Maritime Security Advisory Committee, 2703 Martin Luther King Jr. Avenue SE, Washington, DC 20593, Stop 7581, Washington, DC 20593-7581; telephone 202-302-6565 or via email at 
                        <E T="03">ryan.f.owens@uscg.mil.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Notice of this meeting is in compliance with the 
                    <E T="03">Federal Advisory Committee Act,</E>
                     (Pub. L. 117-286, 5 U.S.C., ch. 10). The Committee is authorized, by section 601 of the 
                    <E T="03">Frank LoBiondo Coast Guard Authorization Act of 2018,</E>
                     Public Law 115-282, 132 Stat. 4192, and is codified in 46 U.S.C. 70112. The Committee operates under the provisions of the 
                    <E T="03">Federal Advisory Committee Act</E>
                     and 46 U.S.C. 15109. The National Maritime Security Advisory Committee provides advice, consults with, and makes recommendations to the Secretary of Homeland Security, via the Commandant of the U.S. Coast Guard, on matters relating to national maritime security.
                </P>
                <HD SOURCE="HD1">Agenda</HD>
                <HD SOURCE="HD2">Monday, February 5, 2024</HD>
                <P>(1) Call to Order.</P>
                <P>(2) Introduction.</P>
                <P>(3) Designated Federal Officer Remarks.</P>
                <P>(4) Roll call of Committee members and determination of quorum.</P>
                <P>(5) Remarks from Committee Leadership.</P>
                <P>(6) Discussion of Task T-2023-01: Update of NVIC 03-03, “Implementation Guidance for the Regulations Mandated by the Maritime Transportation Security Act of 2002 for Facilities.”</P>
                <P>(7) Public Comment Period.</P>
                <P>(8) Adjournment of Meeting.</P>
                <HD SOURCE="HD2">Tuesday, February 6, 2024</HD>
                <P>(1) Call to Order.</P>
                <P>(2) Introduction.</P>
                <P>(3) Roll call of Committee members and determination of quorum.</P>
                <P>(4) Discussion of Task T-2023-02: Active Shooter/Active Threat in the Maritime Environment.</P>
                <P>(5) Public Comment Period.</P>
                <P>(6) Adjournment of Meeting.</P>
                <HD SOURCE="HD2">Wednesday, February 7, 2024</HD>
                <P>(1) Call to Order.</P>
                <P>(2) Introduction.</P>
                <P>(3) Roll call of Committee members and determination of quorum.</P>
                <P>(4) Discussion of Task T-2023-03: Unmanned Systems in the Maritime Environment.</P>
                <P>(5) Public Comment Period.</P>
                <P>(6) Adjournment of Meeting.</P>
                <P>
                    A copy of all meeting documentation will be available at 
                    <E T="03">https://homeport.uscg.mil/NMSAC</E>
                     no later than February 4, 2024. Alternatively, you may contact Mr. Ryan Owens as noted in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section above.
                </P>
                <P>
                    There will be a public comment period at the end of meetings. Speakers are requested to limit their comments to 3 minutes. Please note that the public comment period may end before the period allotted, following the last call for comments. Please contact the individual listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section above to register as a speaker.
                </P>
                <SIG>
                    <DATED>Dated: December 21, 2023.</DATED>
                    <NAME>Amy M. Beach,</NAME>
                    <TITLE>Captain, U.S. Coast Guard, Director of Inspections and Compliance.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00175 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-04-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-4711-DR; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Kentucky; Amendment No. 2 to Notice of a Major Disaster Declaration</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice amends the notice of a major disaster declaration for the Commonwealth of Kentucky (FEMA-4711-DR), dated May 9, 2023, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This change occurred on December 15, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Federal Emergency Management Agency (FEMA) hereby gives notice that pursuant to the authority vested in the Administrator, under Executive Order 12148, as amended, E. Craig Levy Sr., of FEMA is appointed to act as the Federal Coordinating Officer for this disaster.</P>
                <P>This action terminates the appointment of John E. Brogan as Federal Coordinating Officer for this disaster.</P>
                <EXTRACT>
                    <PRTPAGE P="1113"/>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00239 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-4671-DR; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Puerto Rico; Amendment No. 18 to Notice of a Major Disaster Declaration</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice amends the notice of a major disaster declaration for the Commonwealth of Puerto Rico (FEMA-4671-DR), dated September 21, 2022, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This change occurred on December 15, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Federal Emergency Management Agency (FEMA) hereby gives notice that pursuant to the authority vested in the Administrator, under Executive Order 12148, as amended, Robert Little III, of FEMA is appointed to act as the Federal Coordinating Officer for this disaster.</P>
                <P>This action terminates the appointment of DuWayne Tewes Casper as Federal Coordinating Officer for this disaster.</P>
                <EXTRACT>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00236 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-4750-DR; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>California; Major Disaster and Related Determinations</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</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 California (FEMA-4750-DR), dated November 21, 2023, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The declaration was issued November 21, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Notice is hereby given that, in a letter dated November 21, 2023, the President issued a major disaster declaration under the authority of the Robert T. Stafford Disaster Relief and Emergency Assistance Act, 42 U.S.C. 5121 
                    <E T="03">et seq.</E>
                     (the “Stafford Act”), as follows:
                </P>
                <EXTRACT>
                    <P>
                        I have determined that the damage in certain areas of the State of California resulting from Tropical Storm Hilary during the period of August 19 to August 21, 2023, is of sufficient severity and magnitude to warrant a major disaster declaration under the Robert T. Stafford Disaster Relief and Emergency Assistance Act, 42 U.S.C. 5121 
                        <E T="03">et seq.</E>
                         (the “Stafford Act”). Therefore, I declare that such a major disaster exists in the State of California.
                    </P>
                    <P>In order to provide Federal assistance, you are hereby authorized to allocate from funds available for these purposes such amounts as you find necessary for Federal disaster assistance and administrative expenses.</P>
                    <P>You are authorized to provide Public Assistance in the designated areas and Hazard Mitigation throughout the State. Consistent with the requirement that Federal assistance be supplemental, any Federal funds provided under the Stafford Act for Public Assistance and Hazard Mitigation will be limited to 75 percent of the total eligible costs.</P>
                    <P>Further, you are authorized to make changes to this declaration for the approved assistance to the extent allowable under the Stafford Act.</P>
                </EXTRACT>
                <P>The Federal Emergency Management Agency (FEMA) hereby gives notice that pursuant to the authority vested in the Administrator, under Executive Order 12148, as amended, Andrew F. Grant, of FEMA is appointed to act as the Federal Coordinating Officer for this major disaster.</P>
                <P>The following areas of the State of California have been designated as adversely affected by this major disaster:</P>
                <EXTRACT>
                    <P>Imperial, Inyo, Kern, Riverside, and Siskiyou Counties for Public Assistance.</P>
                    <P>All areas within the State of California are eligible for assistance under the Hazard Mitigation Grant Program.</P>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00244 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-3599-EM; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Massachusetts; Amendment No. 1 to Notice of a Major Disaster Declaration</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <PRTPAGE P="1114"/>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice amends the notice of an emergency declaration for the Commonwealth of Massachusetts (FEMA-3599-EM), dated September 15, 2023, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This change occurred on October 2, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Federal Emergency Management Agency (FEMA) hereby gives notice that pursuant to the authority vested in the Administrator, under Executive Order 12148, as amended, William F. Roy, of FEMA is appointed to act as the Federal Coordinating Officer for this emergency.</P>
                <P>This action terminates the appointment of E. Craig Levy, Sr. as Federal Coordinating Officer for this emergency.</P>
                <EXTRACT>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00230 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-3603-EM; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Virgin Islands; Emergency and Related Determinations</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</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 an emergency for the territory of the U.S. Virgin Islands (FEMA-3603-EM), dated November 18, 2023, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The declaration was issued November 18, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Notice is hereby given that, in a letter dated November 18, 2023, the President issued an emergency declaration under the authority of the Robert T. Stafford Disaster Relief and Emergency Assistance Act, 42 U.S.C. 5121-5207 (the Stafford Act), as follows:</P>
                <EXTRACT>
                    <P>
                        I have determined that the emergency conditions in certain areas of the territory of the U.S. Virgin Islands resulting from elevated levels of lead and copper in the water supply beginning on October 25, 2023, and continuing, are of sufficient severity and magnitude to warrant an emergency declaration under the Robert T. Stafford Disaster Relief and Emergency Assistance Act, 42 U.S.C. 5121 
                        <E T="03">et seq.</E>
                         (“the Stafford Act”). Therefore, I declare that such an emergency exists in the territory of the U.S. Virgin Islands.
                    </P>
                    <P>You are authorized to provide appropriate assistance for required emergency measures, authorized under Title V of the Stafford Act, to save lives and to protect property and public health and safety, and to lessen or avert the threat of a catastrophe in the designated areas. Specifically, you are authorized to provide assistance for emergency protective measures (Category B), including direct federal assistance, under the Public Assistance program to provide water, other necessary related items such as filters and testing, and technical assistance necessary to identify and address immediate threats to public health and safety for 90 days from the start of the incident period.</P>
                    <P>Consistent with the requirement that Federal assistance be supplemental, any Federal funds provided under the Stafford Act for Public Assistance will be limited to 75 percent of the total eligible costs. In order to provide Federal assistance, you are hereby authorized to allocate from funds available for these purposes such amounts as you find necessary for Federal emergency assistance and administrative expenses.</P>
                    <P>Further, you are authorized to make changes to this declaration for the approved assistance to the extent allowable under the Stafford Act.</P>
                </EXTRACT>
                <P>The Federal Emergency Management Agency (FEMA) hereby gives notice that pursuant to the authority vested in the Administrator, Department of Homeland Security, under Executive Order 12148, as amended, Lai Sun Yee, of FEMA is appointed to act as the Federal Coordinating Officer for this declared emergency.</P>
                <P>The following areas of the territory of the U.S. Virgin Islands have been designated as adversely affected by this declared emergency:</P>
                <EXTRACT>
                    <P>The island of St. Croix for emergency protective measures, including direct federal assistance, under the Public Assistance program limited to assistance to provide water, other necessary related items such as filters and testing, and technical assistance necessary to identify and address immediate threats to public health and safety for 90 days from the start of the incident period.</P>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00233 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-4751-DR; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Tennessee; Major Disaster and Related Determinations</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</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 Tennessee (FEMA-4751-DR), dated December 13, 2023, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The declaration was issued December 13, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Notice is hereby given that, in a letter dated December 13, 2023, the President issued a major disaster declaration under the authority of the Robert T. Stafford Disaster Relief and Emergency 
                    <PRTPAGE P="1115"/>
                    Assistance Act, 42 U.S.C. 5121 
                    <E T="03">et seq.</E>
                     (the “Stafford Act”), as follows:
                </P>
                <EXTRACT>
                    <P>
                        I have determined that the damage in the State of Tennessee resulting from severe storms and tornadoes on December 9, 2023, is of sufficient severity and magnitude to warrant a major disaster declaration under the Robert T. Stafford Disaster Relief and Emergency Assistance Act, 42 U.S.C. 5121 
                        <E T="03">et seq.</E>
                         (the “Stafford Act”). Therefore, I declare that such a major disaster exists in the State of Tennessee.
                    </P>
                    <P>In order to provide Federal assistance, you are hereby authorized to allocate from funds available for these purposes such amounts as you find necessary for Federal disaster assistance and administrative expenses.</P>
                    <P>You are authorized to provide Individual Assistance and assistance for emergency protective measures (Category B), limited to direct Federal assistance, under the Public Assistance program in the designated areas, Hazard Mitigation throughout the State, and any other forms of assistance under the Stafford Act that you deem appropriate subject to completion of Preliminary Damage Assessments (PDAs).</P>
                    <P>Consistent with the requirement that Federal assistance is supplemental, any Federal funds provided under the Stafford Act for Public Assistance, Hazard Mitigation, and Other Needs Assistance under section 408 will be limited to 75 percent of the total eligible cost.</P>
                    <P>Further, you are authorized to make changes to this declaration for the approved assistance to the extent allowable under the Stafford Act.</P>
                </EXTRACT>
                <P>The time period prescribed for the implementation of section 310(a), Priority to Certain Applications for Public Facility and Public Housing Assistance, 42 U.S.C. 5153, shall be for a period not to exceed six months after the date of this declaration.</P>
                <P>The Federal Emergency Management Agency (FEMA) hereby gives notice that pursuant to the authority vested in the Administrator, under Executive Order 12148, as amended, Yolanda J. Jackson of FEMA is appointed to act as the Federal Coordinating Officer for this major disaster.</P>
                <P>The following areas of the State of Tennessee have been designated as adversely affected by this major disaster:</P>
                <EXTRACT>
                    <P>Davidson, Dickson, Montgomery, and Sumner Counties for Individual Assistance.</P>
                    <P>Davidson, Dickson, Montgomery, and Sumner Counties for emergency protective measures (Category B), limited to direct federal assistance, under the Public Assistance program.</P>
                    <P>All areas within the State of Tennessee are eligible for assistance under the Hazard Mitigation Grant Program.</P>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00245 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-4663-DR; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Kentucky; Amendment No. 14 to Notice of a Major Disaster Declaration</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice amends the notice of a major disaster declaration for the Commonwealth of Kentucky (FEMA-4663-DR), dated July 29, 2022, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This change occurred on December 15, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Federal Emergency Management Agency (FEMA) hereby gives notice that pursuant to the authority vested in the Administrator, under Executive Order 12148, as amended, E. Craig Levy, Sr., of FEMA is appointed to act as the Federal Coordinating Officer for this disaster.</P>
                <P>This action terminates the appointment of John E. Brogan as Federal Coordinating Officer for this disaster.</P>
                <EXTRACT>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00235 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-4749-DR; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Illinois; Major Disaster and Related Determinations</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</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 Illinois (FEMA-4749-DR), dated November 20, 2023, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The declaration was issued November 20, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Notice is hereby given that, in a letter dated November 20, 2023, the President issued a major disaster declaration under the authority of the Robert T. Stafford Disaster Relief and Emergency Assistance Act, 42 U.S.C. 5121 
                    <E T="03">et seq.</E>
                     (the “Stafford Act”), as follows:
                </P>
                <EXTRACT>
                    <P>
                        I have determined that the damage in certain areas of the State of Illinois resulting from severe storms and flooding during the period of September 17 to September 18, 2023, is of sufficient severity and magnitude to warrant a major disaster declaration under the Robert T. Stafford Disaster Relief and Emergency Assistance Act, 42 U.S.C. 5121 
                        <E T="03">et seq.</E>
                         (the “Stafford Act”). Therefore, I declare that such a major disaster exists in the State of Illinois.
                    </P>
                    <P>In order to provide Federal assistance, you are hereby authorized to allocate from funds available for these purposes such amounts as you find necessary for Federal disaster assistance and administrative expenses.</P>
                    <P>
                        You are authorized to provide Individual Assistance in the designated areas and Hazard Mitigation throughout the State. 
                        <PRTPAGE P="1116"/>
                        Consistent with the requirement that Federal assistance be supplemental, any Federal funds provided under the Stafford Act for Hazard Mitigation and Other Needs Assistance under section 408 will be limited to 75 percent of the total eligible costs.
                    </P>
                    <P>Further, you are authorized to make changes to this declaration for the approved assistance to the extent allowable under the Stafford Act.</P>
                </EXTRACT>
                <P>The time period prescribed for the implementation of section 310(a), Priority to Certain Applications for Public Facility and Public Housing Assistance, 42 U.S.C. 5153, shall be for a period not to exceed six months after the date of this declaration.</P>
                <P>The Federal Emergency Management Agency (FEMA) hereby gives notice that pursuant to the authority vested in the Administrator, under Executive Order 12148, as amended, Waddy Gonzalez, of FEMA is appointed to act as the Federal Coordinating Officer for this major disaster.</P>
                <P>The following areas of the State of Illinois have been designated as adversely affected by this major disaster:</P>
                <EXTRACT>
                    <P>Cook County for Individual Assistance.</P>
                    <P>All areas within the State of Illinois are eligible for assistance under the Hazard Mitigation Grant Program.</P>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00243 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-4630-DR; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Kentucky; Amendment No. 12 to Notice of a Major Disaster Declaration</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice amends the notice of a major disaster declaration for the Commonwealth of Kentucky (FEMA-4630-DR), dated December 12, 2021, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This change occurred on December 15, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Federal Emergency Management Agency (FEMA) hereby gives notice that pursuant to the authority vested in the Administrator, under Executive Order 12148, as amended, E. Craig Levy, Sr., of FEMA is appointed to act as the Federal Coordinating Officer for this disaster.</P>
                <P>This action terminates the appointment of John E. Brogan as Federal Coordinating Officer for this disaster.</P>
                <EXTRACT>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00234 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-3600-EM; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Louisiana; Amendment No. 1 to Notice of an Emergency Declaration</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice amends the notice of an emergency declaration for the State of Louisiana (FEMA-3600-EM), dated September 27, 2023, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This amendment was issued November 22, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Notice is hereby given that the emergency assistance being provided under this emergency declaration is extended for an additional 45 days.</P>
                <EXTRACT>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00231 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-3600-EM; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Louisiana; Amendment No. 2 to Notice of an Emergency Declaration</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice amends the notice of an emergency declaration for the State of Louisiana (FEMA-3600-EM), dated September 27, 2023, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This amendment was issued November 30, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The notice of an emergency declaration for the 
                    <PRTPAGE P="1117"/>
                    State of Louisiana is hereby amended to include the following area among those areas determined to have been adversely affected by the event declared an emergency by the President in his declaration of September 27, 2023.
                </P>
                <EXTRACT>
                    <P>St. Mary Parish for emergency protective measures, including direct federal assistance, under the Public Assistance program limited to temporary measures that address reduced water treatment capability due to saltwater intrusion resulting from low water levels of the Mississippi River for no more than 135 days from the date of declaration.</P>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050 Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00232 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-3582-EM; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Mississippi; Amendment No. 1 to Notice of an Emergency Declaration</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice amends the notice of an emergency declaration for the State of Mississippi (FEMA-3582-EM), dated August 30, 2022, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This amendment was issued December 18, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Notice is hereby given that the incident period for this emergency is closed effective November 28, 2022. </P>
                <EXTRACT>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00229 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-4702-DR; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Kentucky; Amendment No. 3 to Notice of a Major Disaster Declaration</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice amends the notice of a major disaster declaration for the Commonwealth of Kentucky (FEMA-4702-DR), dated April 10, 2023, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This change occurred on December 15, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Federal Emergency Management Agency (FEMA) hereby gives notice that pursuant to the authority vested in the Administrator, under Executive Order 12148, as amended, E. Craig Levy, Sr., of FEMA is appointed to act as the Federal Coordinating Officer for this disaster.</P>
                <P>This action terminates the appointment of John E. Brogan as Federal Coordinating Officer for this disaster. </P>
                <EXTRACT>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00238 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-4720-DR; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Vermont; Amendment No. 10 to Notice of a Major Disaster Declaration</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice amends the notice of a major disaster declaration for the State of Vermont (FEMA-4720-DR), dated July 14, 2023, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This amendment was issued November 14, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Notice is hereby given that, in a letter dated November 14, 2023, the President amended the cost-sharing arrangements regarding Federal funds provided under the authority of the Robert T. Stafford Disaster Relief and Emergency Assistance Act, 42 U.S.C. 5121 
                    <E T="03">et seq.</E>
                     (the “Stafford Act”), in a letter to Deanne Criswell, Administrator, Federal Emergency Management Agency, Department of Homeland Security, under Executive Order 12148, as follows:
                </P>
                <EXTRACT>
                    <P>
                        I have determined that the damage in the State of Vermont resulting from severe storms, flooding, landslides, and mudslides during the period of July 7 to July 21, 2023, is of sufficient severity and magnitude that special cost sharing arrangements are 
                        <PRTPAGE P="1118"/>
                        warranted regarding Federal funds provided under the Robert T. Stafford Disaster Relief and Emergency Assistance Act, 42 U.S.C. 5121 
                        <E T="03">et seq.</E>
                         (the “Stafford Act”).
                    </P>
                    <P>Therefore, I amend my declaration of July 14, 2023, and July 17, 2023, to authorize Federal funds for debris removal at 100 percent of the total eligible costs for a continuous 30-day period of the State's choosing within the first 120 days from the start of the incident period.</P>
                    <FP>(The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00240 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-4730-DR; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Alaska; Amendment No. 2 to Notice of a Major Disaster Declaration</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice amends the notice of a major disaster declaration for the State of Alaska (FEMA-4730-DR), dated August 23, 2023, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This change occurred on December 14, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Federal Emergency Management Agency (FEMA) hereby gives notice that pursuant to the authority vested in the Administrator, under Executive Order 12148, as amended, Brian F. Schiller, of FEMA is appointed to act as the Federal Coordinating Officer for this disaster.</P>
                <P>This action terminates the appointment of Lance E. Davis as Federal Coordinating Officer for this disaster.</P>
                <EXTRACT>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00241 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-4748-DR; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Arkansas; Major Disaster and Related Determinations</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</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 Arkansas (FEMA-4748-DR), dated November 14, 2023, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The declaration was issued November 14, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Notice is hereby given that, in a letter dated November 14, 2023, the President issued a major disaster declaration under the authority of the Robert T. Stafford Disaster Relief and Emergency Assistance Act, 42 U.S.C. 5121 
                    <E T="03">et seq.</E>
                     (the “Stafford Act”), as follows:
                </P>
                <EXTRACT>
                    <P>
                        I have determined that the damage in certain areas of the State of Arkansas resulting from severe storms, straight-line winds, and tornadoes during the period of June 25 to June 26, 2023, is of sufficient severity and magnitude to warrant a major disaster declaration under the Robert T. Stafford Disaster Relief and Emergency Assistance Act, 42 U.S.C. 5121 
                        <E T="03">et seq.</E>
                         (the “Stafford Act”). Therefore, I declare that such a major disaster exists in the State of Arkansas.
                    </P>
                    <P>In order to provide Federal assistance, you are hereby authorized to allocate from funds available for these purposes such amounts as you find necessary for Federal disaster assistance and administrative expenses.</P>
                    <P>You are authorized to provide Public Assistance in the designated areas and Hazard Mitigation throughout the State. Consistent with the requirement that Federal assistance be supplemental, any Federal funds provided under the Stafford Act for Public Assistance and Hazard Mitigation will be limited to 75 percent of the total eligible costs.</P>
                    <P>Further, you are authorized to make changes to this declaration for the approved assistance to the extent allowable under the Stafford Act.</P>
                </EXTRACT>
                <P>The Federal Emergency Management Agency (FEMA) hereby gives notice that pursuant to the authority vested in the Administrator, under Executive Order 12148, as amended, Roland W. Jackson, of FEMA is appointed to act as the Federal Coordinating Officer for this major disaster.</P>
                <P>The following areas of the State of Arkansas have been designated as adversely affected by this major disaster:</P>
                <EXTRACT>
                    <P>Arkansas, Faulkner, Lonoke, and Poinsett Counties for Public Assistance.</P>
                    <P>All areas within the State of Arkansas are eligible for assistance under the Hazard Mitigation Grant Program.</P>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00242 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="1119"/>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Internal Agency Docket No. FEMA-4672-DR; Docket ID FEMA-2023-0001]</DEPDOC>
                <SUBJECT>Alaska; Amendment No. 5 to Notice of a Major Disaster Declaration</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice amends the notice of a major disaster declaration for the State of Alaska (FEMA-4672-DR), dated September 23, 2022, and related determinations.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This change occurred on December 14, 2023.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Dean Webster, Office of Response and Recovery, Federal Emergency Management Agency, 500 C Street SW, Washington, DC 20472, (202) 646-2833.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Federal Emergency Management Agency (FEMA) hereby gives notice that pursuant to the authority vested in the Administrator, under Executive Order 12148, as amended, Brian F. Schiller, of FEMA is appointed to act as the Federal Coordinating Officer for this disaster.</P>
                <P>This action terminates the appointment of Lance E. Davis as Federal Coordinating Officer for this disaster.</P>
                <EXTRACT>
                    <P>The following Catalog of Federal Domestic Assistance Numbers (CFDA) are to be used for reporting and drawing funds: 97.030, Community Disaster Loans; 97.031, Cora Brown Fund; 97.032, Crisis Counseling; 97.033, Disaster Legal Services; 97.034, Disaster Unemployment Assistance (DUA); 97.046, Fire Management Assistance Grant; 97.048, Disaster Housing Assistance to Individuals and Households In Presidentially Declared Disaster Areas; 97.049, Presidentially Declared Disaster Assistance—Disaster Housing Operations for Individuals and Households; 97.050, Presidentially Declared Disaster Assistance to Individuals and Households—Other Needs; 97.036, Disaster Grants—Public Assistance (Presidentially Declared Disasters); 97.039, Hazard Mitigation Grant.</P>
                </EXTRACT>
                <SIG>
                    <NAME>Deanne Criswell,</NAME>
                    <TITLE>Administrator, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00237 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9111-23-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HOUSING AND URBAN DEVELOPMENT</AGENCY>
                <DEPDOC>[Docket No. FR-7092-N-03]</DEPDOC>
                <SUBJECT>Privacy Act of 1974; System of Records</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Housing, HUD.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of a Rescindment of a System of Records.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>Pursuant to the provisions of the Privacy Act of 1974, as amended, the Department of the Housing and Urban Development (HUD), the Office of Housing, the Office of Lender Activities and Program Compliance, is issuing a public notice of its intent to rescind the Loan Review System (LRS) because the system does not qualify as a Privacy Act System of Records.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This System of Records rescindment is effective upon publication. The specific date for when this system ceased to be a Privacy Act System of Records is 12/08/2023.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments, identified by one of the following methods:</P>
                    <P>
                        <E T="03">Federal e-Rulemaking Portal: https://www.regulations.gov.</E>
                         Follow the instructions provided on that site to submit comments electronically.
                    </P>
                    <P>
                        <E T="03">Fax:</E>
                         202-619-8365.
                    </P>
                    <P>
                        <E T="03">Email: privacy@hud.gov</E>
                        .
                    </P>
                    <P>
                        <E T="03">Mail:</E>
                         Attention: Privacy Office; LaDonne White, Chief Privacy Officer; The Executive Secretariat; 451 Seventh Street, SW, Room 10139; Washington, DC 20410-0001.
                    </P>
                    <P>
                        <E T="03">Instructions</E>
                        : All submissions received must include the agency name and docket number for this rulemaking. All comments received will be posted without change to 
                        <E T="03">https://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">https://www.regulations.gov</E>
                        .
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        LaDonne White, Chief Privacy Officer, 451 Seventh Street, SW, Room 10139; Washington, DC 20410; telephone number (202) 708-3054 (this is not a toll-free number). HUD welcomes and is prepared to receive calls from individuals who are deaf or hard of hearing, as well as individuals with speech or communication disabilities. To learn more about how to make an accessible telephone call, please visit 
                        <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>The Loan Review System (LRS) is a system developed by HUD for managing and overseeing HUD loans. This system plays a critical role in supporting HUD's mission of creating strong, sustainable, inclusive communities and quality affordable homes for all. It helps ensure that the funds allocated for these purposes are used effectively and responsibly. Its key functions include streamlining the loan review process, risk management, data management and analysis, compliance monitoring, and reporting. The system is designed to be user-friendly and integrates with other HUD systems, ensuring that loans comply with HUD regulations and supporting HUD's mission to provide quality affordable homes and sustainable communities. The retrieval practice was evaluated, and it was determined that records within the system are not retrieved by an individual's personal unique identifier that qualifies for as SORN under the Privacy Act. The Department's Federal Housing Administration (FHA) Case Number or Loan Review ID Number retrieval does not constitute a retrieval for the purpose of the Privacy Act. Records retrieved by FHA-approved lending institutions will continue to be maintained by LRS. </P>
                <PRIACT>
                    <HD SOURCE="HD2">SYSTEM NAME AND NUMBER:</HD>
                    <P>Loan Review System (LRS).</P>
                    <HD SOURCE="HD2">HISTORY:</HD>
                    <P>
                        The previously published notice in the 
                        <E T="04">Federal Register</E>
                         [Docket Number 6009-N-01], on June 6, 2017, 82 FR 26705.
                    </P>
                </PRIACT>
                <SIG>
                    <NAME>Ladonne White,</NAME>
                    <TITLE>Chief Privacy Officer, Office of Administration.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00185 Filed 1-8-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-04]</DEPDOC>
                <SUBJECT>Privacy Act of 1974; System of Records</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Public and Indian Housing, HUD.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of a rescindment of a system of records.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        Pursuant to the provisions of the Privacy Act of 1974, as amended, the Department of the Housing and Urban Development (HUD), Office of Public and Indian Housing, Office of Public Housing and Voucher Programs, is issuing a public notice of its intent to rescind the Tracking-at-a-Glance (TAAG) case management system because this system was a one-time-use 
                        <PRTPAGE P="1120"/>
                        system designed to contain information for a specific population (FEMA eligible referrals), a specific use, and specific amount of time (Disaster Housing Assistance Program (DHAP) eligible families who worked towards self-sufficiency) which ended in 2011.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments will be accepted on or before February 8, 2024. This proposed action will be effective immediately upon publication.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments, identified by one of the following methods:</P>
                    <P>
                        <E T="03">Federal e-Rulemaking Portal: https://www.regulations.gov.</E>
                         Follow the instructions provided on that site to submit comments electronically.
                    </P>
                    <P>
                        <E T="03">Fax:</E>
                         202-619-8365.
                    </P>
                    <P>
                        <E T="03">Email: privacy@hud.gov</E>
                        .
                    </P>
                    <P>
                        <E T="03">Mail:</E>
                         Attention: Privacy Office; LaDonne White, Chief Privacy Officer; The Executive Secretariat; 451 Seventh Street SW, Room 10139; Washington, DC 20410-0001.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions received must include the agency name and docket number for this rulemaking. All comments received will be posted without change to 
                        <E T="03">https://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">https://www.regulations.gov</E>
                        .
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        LaDonne White, Chief Privacy Officer, 451 Seventh Street SW, Room 10139; Washington, DC 20410; telephone number (202) 708-3054 (this is not a toll-free number). HUD welcomes and is prepared to receive calls from individuals who are deaf or hard of hearing, as well as individuals with speech or communication disabilities. To learn more about how to make an accessible telephone call, please visit 
                        <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>The Tracking-at-a-Glance (TAAG) system was used for program implementation activities related to the Disaster Housing Assistance Program (DHAP) case management services. DHAP is a Federal Emergency Management Agency (FEMA) pilot grant program to provide temporary rental subsidies and case management for non-HUD assisted individuals and families displaced by Hurricanes Katrina or Rita. HUD was the servicing agency that administers the DHAP program for FEMA. The program ended in 2011 and none of the records are active because the information would not be eligible for existing HUD or FEMA programs and as such would no longer be needed. Records are no longer maintained by HUD and have run the record retention period. The records were wiped from the system. </P>
                <PRIACT>
                    <HD SOURCE="HD2">SYSTEM NAME AND NUMBER:</HD>
                    <P>Tracking-at-a-Glance (TAAG).</P>
                    <HD SOURCE="HD2">HISTORY:</HD>
                    <P>
                        The previously published notice in the 
                        <E T="04">Federal Register</E>
                         [Docket Number 5130-N-22], on April 23, 2008, 73 FR 21973.
                    </P>
                </PRIACT>
                <SIG>
                    <NAME>Ladonne White,</NAME>
                    <TITLE>Chief Privacy Officer, Office of Administration.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00184 Filed 1-8-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-6435-N-01]</DEPDOC>
                <SUBJECT>Manufactured Housing Consensus Committee (MHCC): Notice Inviting Nominations of Individuals To Serve on the Committee</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Assistant Secretary for Housing—Federal Housing Commissioner, HUD.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of request for nominations to serve on the Manufactured Housing Consensus Committee.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Department of Housing and Urban Development (HUD or the Department) invites the public to nominate individuals for appointment, with the approval of the Secretary, to the Manufactured Housing Consensus Committee (MHCC), a Federal advisory committee established by the National Manufactured Housing Construction and Safety Standards Act of 1974, as amended by the Manufactured Housing Improvement Act of 2000. HUD will make appointments from nominations submitted in response to this Notice but prior nominations on file will not be considered for appointments. Individuals that applied under the previous Notice are strongly encouraged to re-apply under this Notice. Current MHCC members whose first term ends on December 31, 2023, are eligible for reappointment, but will need to submit their nomination to be considered.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The Department will accept nominations until March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Nominations must be submitted through the following website: 
                        <E T="03">https://mhcc.homeinnovation.com/Application.aspx.</E>
                         Submitted nominations must be addressed to: Teresa B. Payne, Administrator, Office of Manufactured Housing Programs, Department of Housing and Urban Development, c/o Home Innovation Research Labs; Attention: Kevin Kauffman, 400 Prince Georges Blvd., Upper Marlboro, MD 20774.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Teresa B. Payne, Administrator, Office of Manufactured Housing Programs, Department of Housing and Urban Development, 451 7th Street SW, Room 9166, Washington, DC 20410; telephone 202-402-2698 (this is not a toll-free number), email 
                        <E T="03">mhcc@hud.gov.</E>
                         HUD welcomes and is prepared to receive calls from individuals who are deaf or hard of hearing, as well as individuals with speech or communication disabilities. To learn more about how to make an accessible telephone call, please visit 
                        <E T="03">https://www.fcc.gov/consumers/guides/telecommunications-relay-service-trs.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>Section 604 of the Manufactured Housing Improvement Act of 2000 (Pub. L. 106-569) amended the National Manufactured Housing Construction and Safety Standards Act of 1974 (42 U.S.C. 5401-5426) (the Act) to require the establishment of the Manufactured Housing Consensus Committee (MHCC), a Federal advisory committee, to: (1) provide periodic recommendations to the Secretary to adopt, revise, and interpret the manufactured housing construction and safety standards; and (2) provide periodic recommendations to the Secretary to adopt, revise, and interpret the procedural and enforcement manufactured housing regulations. The Act authorizes the Secretary to appoint a total of twenty-two members to the MHCC. Twenty-one members have voting rights; the twenty-second member represents the Secretary and is a non-voting position. Service on the MHCC is voluntary. Travel and per diem for meetings is provided in accordance with Federal travel policy pursuant to 5 U.S.C. 5703.</P>
                <P>
                    HUD encourages nominations from highly qualified and motivated individuals of diverse backgrounds, interests, and experience, who meet the requirements set forth in the Act to serve as voting members of the MHCC for up to two terms of three years each. The MHCC expects to meet at least one to two times annually. Meetings may take place by conference call, virtually, or in person. Members of the MHCC undertake additional work commitments on subcommittees and task forces regarding issues under deliberation.
                    <PRTPAGE P="1121"/>
                </P>
                <HD SOURCE="HD1">Nominee Selection and Appointment</HD>
                <P>Members of the MHCC are appointed to serve in one of three member categories. Nominees will be appointed to fill voting member vacancies in the following categories:</P>
                <P>
                    1. 
                    <E T="03">Producers</E>
                    —Seven individuals from producers or retailers of manufactured housing.
                </P>
                <P>
                    2. 
                    <E T="03">Users</E>
                    —Seven individuals representing consumer interests, such as consumer organizations, recognized consumer leaders, and owners who are residents of manufactured homes.
                </P>
                <P>
                    3. 
                    <E T="03">General Interest and Public Officials</E>
                    —Seven general interest and public official members.
                </P>
                <P>The Act provides that the Secretary shall ensure that all interests directly and materially affected by the work of the MHCC have the opportunity for fair and equitable participation without dominance by any single interest. The Secretary may reject the appointment of any one or more individuals to ensure that there is not dominance by any single interest. For purposes of this determination, dominance is defined as a position or exercise of dominant authority, leadership, or influence by reason of superior leverage, strength, or representation.</P>
                <P>Additional requirements governing appointment and member service include:</P>
                <P>(1) Nominees appointed to the User category and three of the individuals appointed to the General Interest and Public Official category shall not have a significant financial interest in any segment of the manufactured housing industry or a significant relationship to any person engaged in the manufactured housing industry.</P>
                <P>(2) Each member serving in the User category shall be subject to a ban disallowing compensation from the manufactured housing industry during the period of, and during the one year following, his or her membership on the MHCC.</P>
                <P>(3) Nominees selected for appointment to the MHCC shall be required to provide disclosures and certifications regarding conflict-of-interest and eligibility for membership prior to finalizing an appointment.</P>
                <P>All selected nominees will be required to submit certifications of eligibility under the foregoing criteria, as a prerequisite to final appointment.</P>
                <HD SOURCE="HD1">Consensus Committee—Advisory Role</HD>
                <P>The MHCC's role is solely to advise the Secretary on the subject matter described above.</P>
                <HD SOURCE="HD1">Federal Advisory Committee Act</HD>
                <P>The MHCC is subject to the requirements of the Federal Advisory Committee Act (5 U.S.C. Ch. 10), 41 CFR part 102-3 (the FACA Final Rule), and to the Presidential Memorandum, dated June 18, 2010, directing all heads of executive departments and agencies not to make any new appointments or reappointments of federally registered lobbyists to advisory committees and other boards and commissions. The June 18, 2010, Presidential Memorandum authorized the Director of the Office of Management and Budget (OMB) to issue guidance to implement this policy. On August 13, 2014, OMB issued guidance regarding the prohibition against appointing or re-appointing federally registered lobbyists to clarify that the ban applies to persons serving on advisory committees, boards, and commissions in their individual capacity and does not apply if they are specifically appointed to represent the interests of a nongovernmental entity, a recognizable group of persons or nongovernmental entities (an industry sector, labor unions, environmental groups, etc.), or state or local governments (79 FR 47482).</P>
                <HD SOURCE="HD1">Term of Office</HD>
                <P>MHCC members serve at the discretion of the Secretary or for a three-year term, up to two terms.</P>
                <HD SOURCE="HD1">Nominee Information</HD>
                <P>
                    Individuals seeking nomination to the MHCC should submit detailed information documenting their qualifications as addressed in the Act and this Notice. In furtherance of Executive Order 14035, 
                    <E T="03">Executive Order on Diversity, Equity, and Inclusion, and Accessibility in the Federal Workforce</E>
                     (86 FR 34593), HUD seeks for the MHCC to reflect the diversity of stakeholders in the housing market. The nomination website listed above, therefore, contains questions to elicit demographic information. Nominees may briefly summarize why they want to be a member of the MHCC and include unique skills, knowledge, and experiences that they would bring to inform the work of the committee. Individuals may nominate themselves. HUD recommends that the application for nomination be accompanied by a resume.
                </P>
                <HD SOURCE="HD1">Additional Information</HD>
                <P>The Department will make appointments and reappointments from nominations submitted in response to this Notice. To be considered for appointment to a position of an MHCC member whose term will expire in December of 2023 or to fill any MHCC vacancy that currently exists, the application must be submitted by March 11, 2024. Appointments will be made at the discretion of the Secretary.</P>
                <SIG>
                    <NAME>Julia R. Gordon,</NAME>
                    <TITLE>Assistant Secretary for Housing—Federal Housing Commissioner.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00180 Filed 1-8-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-02]</DEPDOC>
                <SUBJECT>Privacy Act of 1974; System of Records</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Public and Indian Housing, HUD.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of a modified system of records.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>Under the Privacy Act of 1974, as amended, the Department of Housing and Urban Development (HUD), Office of Public and Indian Housing (PIH) is modifying system of records notice, the Inventory Management System (IMS), also known as the Public and Indian Housing Information Center (IMS/PIC), to amend and replace the current system of records with one that encompasses both the IMS/PIC and the Housing Information Portal (HIP) system, add three new routine uses and a new collection authority. The updates are explained in the “Supplementary Section” of this notice. The system name is changing from IMS/PIC to IMS/PIC-HIP because HUD is adding functionality from HIP to the IMS/PIC system. The existing scope, objectives, business processes, and uses being made of the data by HUD remains unchanged.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments will be accepted on or before February 8, 2024. The SORN becomes effective immediately, while the routine uses become effective after the comment period immediately upon publication except for the routine uses, which will become effective on the date following the end of the comment period unless comments are received which result in a contrary determination.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments, identified by docket number or by one of these methods:</P>
                    <P>
                        <E T="03">Federal e-Rulemaking Portal: http://www.regulations.gov.</E>
                         Follow the instructions provided on that site to submit comments electronically.
                    </P>
                    <P>
                        <E T="03">Fax:</E>
                         202-619-8365.
                        <PRTPAGE P="1122"/>
                    </P>
                    <P>
                        <E T="03">Email: privacy@hud.gov</E>
                        .
                    </P>
                    <P>
                        <E T="03">Mail:</E>
                         Attention: Privacy Office; Mr. Ladonne White, Chief Privacy Officer, Office of the Executive Secretariat; 451 Seventh Street SW, Room 10139, Washington, DC 20410-0001.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions received must include the agency name and docket number for this rulemaking. 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>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        LaDonne White, 451 Seventh Street SW, Room 10139, Washington, DC 20410-0001, telephone number (202) 708-3054 (this is not a toll-free number). HUD welcomes and is prepared to receive calls from individuals who are deaf or hard of hearing, as well as individuals with speech or communication disabilities. To learn more about how to make an accessible telephone call, please visit 
                        <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>
                    The Housing Information Portal (HIP) system will replace, enhance, and augment the functionality currently performed by Inventory Management System and Public and Indian Housing Information Center (IMS/PIC), while reducing the administrative burden on Public Housing Authorities (PHAs) for providing information to HUD through a new form/data submission mechanism. HIP is a modernized, flexible, scalable, internet-based integrated system, which enables PHA, Tribe/Tribally Designated Housing Entities (TDHE) and HUD users to access a common database of affordable housing information via the internet. IMS/PIC and HIP will operate in parallel until such time as HIP is able to fully replace IMS/PIC. The enhanced technology used by the HIP system will also enable critical new policy initiatives, including the expansion of the Moving to Work (MTW) Expansion program mandated by the 2016 Consolidated Appropriations Act and several programmatic changes resulting from the Housing Opportunities Through Modernization Act of 2016 (HOTMA). HUD is publishing this notice to amend and replace the current system of records titled as IMS/PIC with one that encompasses both the IMS/PIC and HIP systems, add three new routine uses to the Routine Use Section and add to the collection authority section published in the 
                    <E T="04">Federal Register</E>
                     on March 25, 2019, at 84 FR 11117. The three new additions to the Routine Uses section allow for sharing of data with Universal Service Administrative Company (USAC)/Federal Communications Commission (FCC) to establish eligibility for benefits administered by USAC for families which also participate in a HUD rental assistance program, and to any Federal, State, or local agency to verify the accuracy and completeness of the eligibility data for HUD rental assistance program, and HUD to enter into cooperative agreements and other types of agreements for the purposes of statistical analysis and research in support of program operations. The addition to the collection authority covers the data collected by Tribes/TDHE and their-hired management agents and entered HIP via the Tribal HUD-Veterans Affairs Supportive Housing (VASH) reporting tool. The changes also include an update to the name of the system manager.
                </P>
                <PRIACT>
                    <HD SOURCE="HD2">SYSTEM NAME AND NUMBER:</HD>
                    <P>Inventory Management System, Public and Indian Housing Information Center (IMS/PIC) and Housing Information Portal (HIP), HUD/PIH-01.</P>
                    <HD SOURCE="HD2">SECURITY CLASSIFICATION:</HD>
                    <P>Unclassified.</P>
                    <HD SOURCE="HD2">SYSTEM LOCATION:</HD>
                    <P>Records are maintained at these locations: U.S. Department of Housing and Urban Development Headquarters, 451 Seventh Street SW, Washington, DC 20410-0001; IMS/PIC servers are in Charleston, WV; and are accessed through the internet. The servers are maintained by HUD Information Technology Services (HITS) contractor, and HUD's information technology partner: Perspecta. 15052 Conference Center Drive, Chantilly, VA 20151.</P>
                    <HD SOURCE="HD2">SYSTEM MANAGER(S):</HD>
                    <P>Ashley Sheriff, Deputy Assistant Secretary, Real Estate Assessment Center (REAC), 550 12th Street SW, Suite 100, Washington, DC 20410. (202) 475-7949.</P>
                    <HD SOURCE="HD2">AUTHORITY FOR MAINTENANCE OF THE SYSTEM:</HD>
                    <P>
                        United States Housing Act of 1937 (42 U.S.C. 1437, 
                        <E T="03">et seq.</E>
                        ); Title VI of the Civil Rights Act of 1962 (42 U.S.C. 2000d); The Fair Housing Act (42 U.S.C. 3601-3619); The Housing Community Development Act of 1981, Public Law 97-35, 85 Stat. 348,408; The Housing and Community Development Act of 1987 (42 U.S.C. 3543); and the Native American Housing Assistance and Self-Determination Act of 1996, Public Law 104-330, 110 Stat. 4016.
                    </P>
                    <HD SOURCE="HD2">PURPOSE(S) OF THE SYSTEM:</HD>
                    <P>IMS/PIC and HIP serve as a national repository of information related to PHAs, Tribally Designated Housing Entities (TDHE), HUD-assisted families, HUD assisted properties, and other HUD programs, for the purpose of monitoring and evaluating the effectiveness of PIH rental housing assistance programs. IMS/PIC and HIP allow PHAs, TDHEs, and their-hired management agents to electronically submit information to HUD that is related to the administration of HUD's PIH programs. They collect data for PIH operations, including data submitted via the internet from HUD's field offices, and accurately tracks activities and processes. IMS/PIC and HIP also help to increase sharing of information throughout PIH and HUD, which improves staff awareness of activities related to the administration of HUD subsidized housing programs. IMS/PIC and HIP are flexible, scalable, internet-based integrated systems, which enables PHA and TDHE users, and HUD personnel to access a common database via their web browser. IMS/PIC and HIP aids HUD and entities that administer HUD's assisted housing programs in: (a) Increasing the effective distribution of rental assistance to individuals that meet the requirements of Federal rental assistance programs; (b) detecting abuses in assisted housing programs; (c) taking administrative or legal actions to resolve past and current abuses of assisted housing programs; (d) monitoring compliance with HUD program requirements; (e) deterring abuses by verifying the employment and income of tenants at the time of annual and interim reexaminations of family income and composition via the PIH Enterprise Income Verification (EIV) system; (f) evaluating program effectiveness; (g) improving PHA and TDHE IMS/PIC and HIP reporting rates; (h) forecasting budgets; (i) controlling funds; (j) updating tenant information; and (k) updating building and unit data.</P>
                    <HD SOURCE="HD2">CATEGORIES OF INDIVIDUALS COVERED BY THE SYSTEM:</HD>
                    <P>
                        Families residing in a HUD-assisted property and/or receiving rental housing assistance via programs administered by the Department of Housing and Urban Development; PHAs and their hired management agents; TDHEs and their hired management agents; and individuals who have received or applied for housing-related disaster assistance from the Federal Emergency Management Agency (FEMA).
                        <PRTPAGE P="1123"/>
                    </P>
                    <HD SOURCE="HD2">CATEGORIES OF RECORDS IN THE SYSTEM:</HD>
                    <P>Records consist of the following information as reported to HUD by PHAs, TDHEs, and their hired management agents, and other governmental agencies:</P>
                    <P>1. Agency information: Agency name, HUD-assigned code, HUD program type family participates in; project number, building number, building number, building entrance number, and unit number (applicable to only the Public Housing program).</P>
                    <P>2. Agency contact information.</P>
                    <P>
                        a. Agency point of contact information for individuals that work for, and access IMS/PIC and HIP and oversee the agency's administration (
                        <E T="03">i.e.,</E>
                         Mayors, board members, managers, directors, etc.: Individual's name, agency's physical address, agency's mailing address, agency's telephone numbers, and email addresses for point of contacts).
                    </P>
                    <P>b. PHA and TDHE IMS/PIC and HIP system user's information: Name, telephone number, fax number, email address, mailing address, agency website address.</P>
                    <P>3. Action information: Type of action (new admission, annual reexamination, interim reexamination, portability move-in, portability move-out, end of participation, other change of unit, Family Self-sufficiency (FSS), annual reexamination searching (Section 8 program only), issuance of voucher (Section 8 program only), expiration of voucher (Section 8 program only), flat rent annual updated (Public Housing program only), annual HQS inspection (Section 8 program only), historical adjustment, and void); effective date of action, indication of correction of previous submitted information, type of correction, date family was admitted into a PIH rental assistance program, projected effective date of next reexamination of family income and/or composition, projected date of next flat rent annual updated (applicable only to the Public Housing program), indication of whether or not the family is or has participated in the FSS program within the last year, identification of special Section 8 program (applicable only to the Section 8 program), identification of other special HUD rental program(s) the family is participating in, and “PHA Use Only” fields which are used by PHAs for general administrative purposes or other uses as prescribed by HUD.</P>
                    <P>4. Family composition (which includes the following personally identifiable information) as reported by the family and verified by PHAs, TDHEs, and their-hired management agents: Last name, first name, middle initial, place of birth, date of birth, age (age on effective date of action), sex, gender, relationship to head of household, citizenship status, disability status, race, ethnicity, social security number, tax identification number, alien registration number, compliance with community service or self-sufficiency requirement for public housing tenants, total number of household members, family subsidy status under the noncitizens rule, eligibility effective date, and former head of household's social security number.</P>
                    <P>5. Geographical and unit information:</P>
                    <P>a. Background at admission information as reported by the family: Date family entered the waiting list, zip code before admission, whether or not the family was homeless at time of admission, whether or not the family qualifies for admission over the very low-income limit, whether or not the family is continuously assisted under the 1937 Housing Act, whether or not there is a HUD-approved income targeting disregard.</P>
                    <P>b. Subsidized Unit information: Unit number and street address, city, State and zip code in which the subsidized unit is located, city, State and zip code in which the subsidized unit is located, whether or not the family's mailing address is the same address of the unit to be occupied by the family, family's mailing address (unit number and street address, city, State, and zip code) if different from the address of the subsidized unit, number of bedrooms, whether or not the unit is an accessible unit (applicable to the Public Housing program only), whether or not the family has requested accessibility features (applicable to the Public Housing program only), whether or not the family has received the requested accessibility features (applicable to the Public Housing program only), date the unit last passed Housing Quality Standards (HQS) inspection (applicable to the Section 8 program only, except Homeownership and Project-Based Vouchers programs), date of last annual HQS inspection (applicable to the Section 8 program only, except Homeownership and Project-Based Vouchers programs), year the unit was built (applicable to the Section 8 program only), and the structure type of the unit (applicable to the Section 8 program only).</P>
                    <P>6. Family assets information, as reported by the family and verified by PHAs, TDHEs, and their hired management agents, which includes the type of asset, cash value of the asset, anticipated annual income derived from the asset, passbook rate, imputed asset income, and final asset income.</P>
                    <P>7. Family income information, as reported by the family and verified by PHAs, TDHEs, and their hired management agents, which includes the income source, Income calculations, annual income derived from the income source, income exclusion amount in accordance with HUD program requirements and annual income amount after deducting allowable income exclusion for each household member of the family, total household annual income, amounts of permissible deductions and other deductions to annual income in accordance with HUD program requirements, and amount of family adjusted annual income.</P>
                    <P>8. Total tenant payment (TTP), minimum rent amount, most recent TTP amount, and tenant rent calculation information in accordance with HUD requirements for the specific PIH rental assistance program the family is currently participating in.</P>
                    <P>9. Family Self-sufficiency (FSS) program information: Type of self-sufficiency program the family is participating in, FSS report category, FSS effective date, PHA code of PHA administering FSS contract, and general information pertaining to the employment status of the head of household, date current employment began, type of employment benefits head of household receives from employer, number of years of school completed by the head of household, type of other Federal assistance received by the family, number of children receiving childcare services, and optional information related to the type of family services the family needs, whether or not the need was met during participation in the FSS program, and the name of the service provider; FSS contract, account and exit information; and FSS contract, account and exit information.</P>
                    <P>10. Disaster assistance information: Records from FEMA, shared with HUD pursuant to an approved computer matching agreement, to enable effective delivery of aid in the wake of a disaster. Includes information about applicants for FEMA assistance, including name, social security number, address, type and amount of disaster damage, type and amount of assistance provided by FEMA.</P>
                    <HD SOURCE="HD2">RECORD SOURCE CATEGORIES:</HD>
                    <P>
                        Individuals, HUD staff; HUD contractors; PHAs, TDHEs, and their hired management agents; the Social Security Administration; the Department of Veteran Affairs; the Federal Emergency Management Agency; and other Federal, State and local agencies. The IMS/PIC and HIP 
                        <PRTPAGE P="1124"/>
                        data reported by PHAs, TDHEs, and their hired management agents is electronically transmitted to IMS/PIC and HIP using agency owned software or via HUD's Family Reporting Software (FRS). The Tribal HUD-VASH module in HIP is used by the TDHEs and their hired management agents to record data as required by the Tribal HUD-VASH program.
                    </P>
                    <HD SOURCE="HD2">ROUTINE USES OF RECORDS MAINTAINED IN THE SYSTEM, INCLUDING CATEGORIES OF USERS AND PURPOSES OF SUCH USES:  </HD>
                    <P>
                        1. To the National Archives and Records Administration, Office of Government Information Services (OGIS), to the extent necessary to fulfill its responsibilities in 
                        <E T="03">5 U.S.C. 552(h),</E>
                         to review administrative agency policies, procedures and compliance with the Freedom of Information Act (FOIA), and to facilitate OGIS' offering of mediation services to resolve disputes between persons making FOIA requests and administrative agencies.
                    </P>
                    <P>2. To the HUD Geocoding Service Center (GSC) to obtain geographic information for records in the system.</P>
                    <P>3. To individuals under contract to HUD or under contract to another agency with funds provided by HUD: For the preparation of studies and statistical reports directly related to the management of HUD's rental assistance programs, to support quality control for tenant eligibility efforts requiring a random sampling of tenant files to determine the extent of administrative errors in making rent calculations, eligibility determinations, etc., and for processing reexaminations (individuals provided information under this routine use are subject to Privacy Act requirements and limitation on disclosures as are applicable to HUD officials and employees).</P>
                    <P>4. To PHAs, TDHEs, and their hired management agents, and auditors of HUD rental housing assistance programs: To verify the accuracy and completeness of tenant data used in determining eligibility and continued eligibility and the amount of housing assistance received.</P>
                    <P>5. To PHAs, TDHEs, and their hired management agents of HUD rental housing assistance programs: To identify and resolve discrepancies in tenant data.</P>
                    <P>6. To researchers affiliated with academic institutions, with not-for profit organizations, or with Federal, State or local governments, or to policy researchers: Without personally identifiable information: For the performance of research and statistical activities on housing and community development issues (individuals provided information under this routine use are subject to Privacy Act requirements and limitation on disclosures as are applicable to HUD officials and employees).</P>
                    <P>7. To HUD contractors, independent public auditors and accountants, PHAs, and TDHEs: For the purpose of conducting oversight and monitoring of program operations to determine compliance with applicable laws and regulations, and financial reporting requirements (individuals provided information under this routine use are subject to Privacy Act requirements and limitation on disclosures as are applicable to HUD officials and employees).</P>
                    <P>8. To the U.S. Department of Veterans Affairs (VA) for statistical analysis to advance the goals of the nation's Federal strategic plan to prevent and end homelessness through the collection, analysis, and reporting of quality and timely data on veterans homelessness to assist VA with the establishment and/or verification of the following: Reducing homelessness among our nation's veterans; identify and understand the needs of homeless veterans and to develop programs and services to address those needs; effective administration of the HUD Veterans Affairs Supportive Housing (VASH) program by HUD and VA business partners; HUD-VASH program monitoring and evaluation; and the production of aggregate statistical data without any personal identifiers, which will not be used to make decisions concerning the rights, benefits, or privileges of specific individuals, or providers of services with respect to assistance provided under the HUD-VASH program.</P>
                    <P>9. To the U.S. Department of Veterans Affairs (VA), under an approved computer matching agreement, or data sharing agreement pursuant to a Presidential Executive Order (E.O.) mandate and in accordance with the Federal Privacy Act and Computer Matching and Privacy Protection Act: To identify and recover overpayments (improper payments) of rental assistance, determine compliance with program requirements by program administrators and participants of HUD rental housing assistance programs, deter future abuses in rental housing assistance programs, reduce administrative costs associated with manual program evaluation and monitoring efforts, and ensure that only eligible participants receive rental assistance in the correct amount.</P>
                    <P>10. To the FEMA, under an approved computer matching agreement, or data sharing agreement pursuant to a Presidential E.O. mandate in accordance with the Federal Privacy Act and Computer Matching and Privacy Protection Act: To identify existing families which participate in a HUD rental assistance program and are currently receiving housing assistance.</P>
                    <P>11. To State, local and Tribal governments receiving HUD disaster recovery grants, and to PHAs: To ensure effective delivery of disaster recovery aid, to prevent duplication of benefits between HUD and other Federal agencies, and to address unmet needs of disaster victims.</P>
                    <P>12. To appropriate agencies, entities, and persons when (1) [the agency] suspects or has confirmed that there has been a breach of the system of records,· (2) [the agency] has determined that as a result of the suspected or confirmed breach there is a risk of harm to individuals, [the agency] (including its information systems, programs, and operations), the Federal Government, or national security; and (3) the disclosure made to such agencies, entities, and persons is reasonably necessary to assist in connection with [the agency's] efforts to respond to the suspected or confirmed breach or to prevent, minimize, or remedy such harm.</P>
                    <P>13. To another Federal agency or Federal entity, when [the agency] determines that information from this system of records is reasonably necessary to assist the recipient agency or entity in (1) responding to a suspected or confirmed breach or (2) preventing, minimizing, or remedying the risk of harm to individuals, the recipient agency or entity (including its information systems, programs, and operations), the Federal Government, or national security, resulting from a suspected or confirmed breach.</P>
                    <P>
                        14. To the Universal Service Administrative Company (USAC), which is designated by the Federal Communications Commission (FCC) as the Federal administrator of the Universal Service Fund (USF or Fund) Lifeline Program (Lifeline), the Emergency Broadband Benefit (EBB) program and other Federal Telecommunications Benefit (FTB) programs that utilizes Lifeline eligibility criteria as specified by the Lifeline program, 
                        <E T="03">47 CFR 54.409</E>
                        . The purpose of this routine use is to establish eligibility for the Lifeline, EBB and other FTB programs for families which also participate in a HUD rental assistance program.
                    </P>
                    <P>
                        15. To any Federal, State, or local agency (
                        <E T="03">e.g.,</E>
                         State agencies administering the State's unemployment compensation laws, Temporary Assistance to Needy Families, or 
                        <PRTPAGE P="1125"/>
                        Supplemental Nutrition Assistance Program agencies, U.S. Department of Health and Human Services, and U.S. Social Security Administration): To verify the accuracy and completeness of the data provided, to verify eligibility or continued eligibility in HUD's rental assistance programs, to identify and recover improper payments under the Payment Integrity Information Act of 2019, 
                        <E T="03">Public Law 116-117.,</E>
                         and to aid in the identification of tenant errors, fraud, and abuse in assisted housing programs.
                    </P>
                    <P>16. To contractors, grantees, experts, consultants, Federal agencies, and non-Federal entities, including, but not limited to, State and local governments and other research institutions or their parties, and entities and their agents with whom HUD has a contract, service agreement, grant, cooperative agreement, or other agreement for the purposes of statistical analysis and research in support of program operations, management, performance monitoring, evaluation, risk management, and policy development, or to otherwise support the Department's mission. Research and analysis activities may include the matching of the records in this system with information from any other source.</P>
                    <HD SOURCE="HD2">POLICIES AND PRACTICES FOR STORAGE OF RECORDS:</HD>
                    <P>Electronic and paper.</P>
                    <HD SOURCE="HD2">POLICIES AND PRACTICES FOR RETRIEVAL OF RECORDS:</HD>
                    <P>Records are retrieved by name and Social Security Number.</P>
                    <HD SOURCE="HD2">POLICIES AND PRACTICES FOR RETENTION AND DISPOSAL OF RECORDS:</HD>
                    <P>
                        Electronic records are maintained and destroyed in accordance with requirements of the HUD Records Disposition Schedule, 2225-6. In accordance with 
                        <E T="03">24 CFR 908.101</E>
                         and HUD record retention requirements at 
                        <E T="03">24 CFR 85.42,</E>
                         PHAs are required to retain at least `three years' worth of IMS/PIC and HIP data either electronically or in paper form.
                    </P>
                    <HD SOURCE="HD2">ADMINISTRATIVE, TECHNICAL, AND PHYSICAL SAFEGUARDS:</HD>
                    <P>Records are maintained at the U.S. Department of Housing and Urban Development in Washington, DC with limited access to those persons whose official duties require the use of such records. Computer files and printed listings are maintained in locked cabinets. User's access, updates access, read-only access, and approval access are granted based on the user's role and security access level.</P>
                    <HD SOURCE="HD2">RECORD ACCESS PROCEDURES:</HD>
                    <P>
                        Individuals requesting records of themselves should address written inquiries to the Department of Housing Urban and Development 451 7th Street SW, Washington, DC 20410-0001. For verification, individuals should provide their full name, current address, and telephone number. In addition, the requester must provide either a notarized statement or an unsworn declaration made under 
                        <E T="03">24 CFR 16.4</E>
                        .
                    </P>
                    <HD SOURCE="HD2">CONTESTING RECORD PROCEDURES:</HD>
                    <P>
                        The HUD rule for contesting the content of any record pertaining to the individual by the individual concerned is published in 
                        <E T="03">24 CFR 16.8</E>
                         or may be obtained from the system manager.
                    </P>
                    <HD SOURCE="HD2">NOTIFICATION PROCEDURES:</HD>
                    <P>
                        Individuals requesting notification of records of themselves should address written inquiries to the Department of Housing Urban Development, 451 7th Street SW, Washington, DC 20410-0001. For verification purposes, individuals should provide their full name, office or organization where assigned, if applicable, and current address and telephone number. In addition, the requester must provide either a notarized statement or an unsworn declaration made under 
                        <E T="03">24 CFR 16.4</E>
                        .
                    </P>
                    <HD SOURCE="HD2">EXEMPTIONS PROMULGATED FOR THE SYSTEM:</HD>
                    <P>None.</P>
                    <HD SOURCE="HD2">HISTORY:</HD>
                    <P>
                        Docket No. FR-7077-N-07 published on March 25, 2019, at 
                        <E T="03">88 FR 17004</E>
                        .
                    </P>
                </PRIACT>
                <SIG>
                    <NAME>LaDonne White,</NAME>
                    <TITLE>Chief Privacy Officer, Office of Administration.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00186 Filed 1-8-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>[FWS-R7-ES-2023-N060; FXES11140700000-234-FF07C00000]</DEPDOC>
                <SUBJECT>Endangered and Threatened Wildlife and Plants; Initiation of 5-Year Status Reviews of the Aleutian Shield Fern and the Alaska Breeding Population of Steller's Eider</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Fish and Wildlife Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; request for information.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>We, the U.S. Fish and Wildlife Service, are initiating 5-year status reviews of the Aleutian shield fern and the Alaska breeding population of Steller's eider under the Endangered Species Act. A 5-year status review is based on the best scientific and commercial data available at the time of the review. We are requesting submission of any new information on these species that has become available since the last reviews of the species. We invite comments and information from the public and local, State, Tribal, and Federal agencies.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>To ensure consideration of your comments in our preparation of these 5-year status reviews, we must receive your comments and information by March 11, 2024. However, we will accept information about any species at any time.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>For Aleutian shield fern, please submit your information by one of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Email: sabrina_farmer@fws.gov;</E>
                         or
                    </P>
                    <P>
                        • 
                        <E T="03">U.S. mail or hand delivery:</E>
                         U.S. Fish and Wildlife Service, Attention: Sabrina Farmer, Southern Alaska Fish and Wildlife Field Office, 4700 BLM Road, Anchorage, AK 99507.
                    </P>
                    <P>For the Alaska breeding population of Steller's eider, please submit your information by one of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Email: nathan_graff@fws.gov;</E>
                         or
                    </P>
                    <P>
                        • 
                        <E T="03">U.S. mail or hand-delivery:</E>
                         U.S. Fish and Wildlife Service, Attention: Nathan Graff, Northern Alaska Fish and Wildlife Field Office, 101 12th Avenue, Fairbanks, AK 99701.
                    </P>
                    <P>
                        For more about submitting information, see Request for Information in the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For Aleutian shield fern, contact Sabrina Farmer, by telephone at 907-271-2778 or by one of the methods in 
                        <E T="02">ADDRESSES</E>
                        .
                    </P>
                    <P>
                        For the Alaska breeding population of Steller's eider, contact Nathan Graff, by telephone at 907-251-9428 or by one of the methods in 
                        <E T="02">ADDRESSES</E>
                        .
                    </P>
                    <P>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>
                    We, the U.S. Fish and Wildlife Service (Service), are initiating 5-year status reviews of the Aleutian shield fern (
                    <E T="03">Polystichum aleuticum</E>
                    ) and the Alaska breeding population of Steller's eider (
                    <E T="03">Polysticta stelleri</E>
                    ) under the Endangered Species Act of 1973, as amended (ESA; 16 U.S.C. 1531 
                    <E T="03">et seq.</E>
                    ). A 5-year status review is based on the best scientific 
                    <PRTPAGE P="1126"/>
                    and commercial data available at the time of the review; therefore, we are requesting submission of any new information on this species that has become available since the last 5-year reviews were conducted in 2019.
                </P>
                <HD SOURCE="HD1">Why do we conduct 5-year reviews?</HD>
                <P>
                    Under the ESA, we maintain Lists of Endangered and Threatened Wildlife and Plants (which we collectively refer to as the List) in the Code of Federal Regulations (CFR) at 50 CFR 17.11 (for animals) and 17.12 (for plants). Section 4(c)(2)(A) of the ESA requires us to review each listed species' status at least once every 5 years. Further, our regulations at 50 CFR 424.21 require that we publish a notice in the 
                    <E T="04">Federal Register</E>
                     announcing those species under active review. For additional information about 5-year reviews, go to 
                    <E T="03">http://www.fws.gov/endangered/what-we-do/recovery-overview.html.</E>
                </P>
                <HD SOURCE="HD1">What information do we consider in our review?</HD>
                <P>In conducting these reviews, we consider the best scientific and commercial data that have become available since the listing determination or most recent status review, such as:</P>
                <P>1. The biology of the species, including but not limited to population trends, distribution, abundance, demographics, and genetics;</P>
                <P>2. Habitat conditions, including but not limited to amount, distribution, and suitability;</P>
                <P>3. Conservation measures that have been implemented that benefit the species;</P>
                <P>4. Threat status and trends in relation to the five listing factors (as defined in section 4(a)(1) of the ESA); and</P>
                <P>5. Other new information, data, or corrections, including but not limited to taxonomic or nomenclatural changes, identification of erroneous information contained in the List, and improved analytical methods.</P>
                <P>Any new information will be considered during the 5-year review and will also be useful in evaluating the ongoing recovery programs for the species.</P>
                <HD SOURCE="HD1">Species Under Review</HD>
                <P>
                    <E T="03">Entity listed:</E>
                     Aleutian shield fern (
                    <E T="03">Polystichum aleuticum</E>
                    ).
                </P>
                <P>
                    • 
                    <E T="03">Where listed:</E>
                     Wherever found.
                </P>
                <P>
                    • 
                    <E T="03">Classification:</E>
                     Endangered.
                </P>
                <P>
                    • 
                    <E T="03">Date listed (publication date for final listing rule):</E>
                     February 17, 1988.
                </P>
                <P>
                    • 
                    <E T="7462">Federal Register</E>
                      
                    <E T="03">citation for final listing rule:</E>
                     53 FR 4626.
                </P>
                <P>
                    <E T="03">Entity listed:</E>
                     Steller's eider (
                    <E T="03">Polysticta stelleri</E>
                    ).
                </P>
                <P>
                    • 
                    <E T="03">Where listed:</E>
                     United States (Alaska breeding population only).
                </P>
                <P>
                    • 
                    <E T="03">Classification:</E>
                     Threatened.
                </P>
                <P>
                    • 
                    <E T="03">Date listed (publication date for final listing rule):</E>
                     June 11, 1997.
                </P>
                <P>
                    • 
                    <E T="7462">Federal Register</E>
                      
                    <E T="03">citation for final listing rule:</E>
                     62 FR 31748.
                </P>
                <HD SOURCE="HD1">Request for Information</HD>
                <P>To ensure that a 5-year review is complete and based on the best available scientific and commercial information, we request new information from all sources. See What Information Do We Consider in Our Review? for specific criteria. If you submit information, please support it with documentation such as maps, bibliographic references, methods used to gather and analyze the data, and/or copies of any pertinent publications, reports, or letters by knowledgeable sources.</P>
                <HD SOURCE="HD1">Public Availability of Comments</HD>
                <P>Before including your address, phone number, email address, or other personal identifying information in your comments, 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>
                <HD SOURCE="HD1">Contents of Submissions</HD>
                <P>Please make your comments as specific as possible. Please confine your comments to issues for which we seek comments in this notice, and explain the basis for your comments. Include sufficient information with your comments to allow us to authenticate any scientific or commercial data you include.</P>
                <P>The comments and recommendations that will be most useful and likely to be relevant to agency decisions are: (1) Those supported by quantitative information or studies; and (2) Those that include citations to, and analyses of, the applicable laws and regulations.</P>
                <HD SOURCE="HD1">Authority</HD>
                <P>
                    This document is published under the authority of the Endangered Species Act of 1973, as amended (16 U.S.C. 1531 
                    <E T="03">et seq.</E>
                    ).
                </P>
                <SIG>
                    <NAME>Peter Fasbender,</NAME>
                    <TITLE>Assistant Regional Director, Fisheries and Ecological Services.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00257 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4333-15-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>Bureau of Land Management</SUBAGY>
                <DEPDOC>[LLCO-923000.L1440000.ET0000; COC 028254]</DEPDOC>
                <SUBJECT>Public Land Order No. 7934; Partial Revocation of Four Secretarial Orders for the Grand Valley Reclamation Project and Opening Order; Colorado</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Bureau of Land Management, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Public Land Order.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This Order partially revokes four withdrawals created by Secretarial Orders dated July 2, 1902, August 26, 1902, February 28, 1908, and July 25, 1908, issued pursuant to the Reclamation Act of June 17, 1902, Section 3, to support the Bureau of Reclamation's (BOR's) Grand Valley Reclamation Project. The BOR has determined that 31.10 acres of the withdrawn land are no longer needed for reclamation purposes and has asked that the withdrawals be partially revoked as to these acres. This Order also opens these 31.10 acres to appropriation under the public land laws, subject to valid existing rights. The land has been and will remain open to mineral leasing and will remain closed to location and entry under the United States mining laws.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This Public Land Order takes effect on January 9, 2024.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Jennifer Jardine, BLM, Colorado State Office, at 970-385-1224, email at 
                        <E T="03">jjardine@blm.gov,</E>
                         or write to Branch of Lands and Realty, P.O. Box 151029, Lakewood, Colorado 80215-7093. Individuals in the United States who are deaf, deafblind, hard of hearing, or have a speech disability may dial 711 (TTY, TDD, or Tele Braille) 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>
                    The BOR requested a partial withdrawal revocation and opening of 31.10 acres of land originally withdrawn in support of the Grand Valley Reclamation Project created by four Secretarial Orders dated July 2, 1902, August 26, 1902, February 28, 1908, and July 25, 1908. The Secretarial Orders classified the land for potential irrigation project purposes. The BOR has determined that the land is no longer needed for reclamation purposes. The revocation of the withdrawal as to these 31.10 acres 
                    <PRTPAGE P="1127"/>
                    would allow the land to be conveyed out of Federal ownership in a proposed land sale. Any land not conveyed will be restored to the administration of the Bureau of Land Management.
                </P>
                <HD SOURCE="HD1">Order</HD>
                <P>By virtue of the authority vested in the Secretary of the Interior by Section 204 of the Federal Land Policy and Management Act of 1976, 43 U.S.C. 1714, it is ordered as follows:</P>
                <P>1. The withdrawals created by Secretarial Orders dated July 2, 1902, August 26, 1902, February 28, 1908, and July 25, 1908, which withdrew public land for use by the Bureau of Reclamation for the Grand Valley Reclamation Project, are hereby partially revoked as to the following described land:</P>
                <P>
                    A parcel of land situated in the southwest quarter (SW
                    <FR>1/4</FR>
                    ) of the northwest quarter (NW
                    <FR>1/4</FR>
                    ) of Section 2, Township 1 South, Range 1 East, Ute Principal Meridian, Mesa County, Colorado, being the results of a survey of an irregular bounded portion of land and being more particularly described as follows:
                </P>
                <P>
                    <E T="03">Commencing</E>
                     at the 
                    <FR>1/4</FR>
                     section corner of sections 2 and 3, marked with a 2
                    <FR>1/2</FR>
                     inch diameter brass disk with illegible marks;
                </P>
                <P>
                    <E T="03">Thence,</E>
                     North 00°00′03″ East, on the line between sections 2 and 3, identical with the right-of-way center line of a Mesa County Road, a distance of 567.65 feet to the 
                    <E T="03">point of beginning</E>
                     of the herein described parcel;
                </P>
                <P>
                    <E T="03">Thence,</E>
                     North 00°00′03″ East, continuing on the section line, identical with the right-of-way line of a Mesa County Road, a distance of 735.03 feet to the north 
                    <FR>1/16</FR>
                     section corner of sections 2 and 3, marked with a 2
                    <FR>1/2</FR>
                     inch diameter plastic pipe with cap marked T1S N
                    <FR>1/16</FR>
                     S3 S2 R1E LS18467 1984;
                </P>
                <P>
                    <E T="03">Thence,</E>
                     South 89°59′55′ East, on the east and west center line of the north half (N
                    <FR>1/2</FR>
                    ) of section 2, a distance of 1313.84 feet to the northwest 
                    <FR>1/16</FR>
                     section corner of section 2, marked with a 2-inch diameter plastic pipe with cap marked T.1S. NW
                    <FR>1/16</FR>
                     S2 R.1E. 18467 1987;
                </P>
                <P>
                    <E T="03">Thence,</E>
                     South 00°07′42″ East, on the north and south center line of the northwest quarter (NW
                    <FR>1/4</FR>
                    ) of section 2, a distance of 724.06 feet to a non-tangential point of curvature to the left, concave southeasterly;
                </P>
                <P>
                    <E T="03">Thence,</E>
                     with said curve through a central (delta) angle of 89°14′37″, having a radius of 169.74 feet, an arc distance of 264.38 feet; the long chord bears South 24°05′46″ West, a distance of 238.46 feet to the point of tangency;
                </P>
                <P>
                    <E T="03">Thence,</E>
                     South 20°31′31″ East, a distance of 86.84 feet to a point of curvature to the right, concave northwesterly;
                </P>
                <P>
                    <E T="03">Thence,</E>
                     with said curve through a central (delta) angle of 105°49′07″, having a radius of 76.15 feet, an arc distance of 140.64 feet; the long chord bears South 32°22′55″ West, a distance of 121.49 feet to the point of tangency;
                </P>
                <P>
                    <E T="03">Thence,</E>
                     South 85°17′24″ West, a distance of 511.91 feet to a point of curvature to the right, concave northeasterly;
                </P>
                <P>
                    <E T="03">Thence,</E>
                     with said curve through a central (delta) angle of 49°51′04″, having a radius of 231.96 feet, an arc distance of 201.82 feet; the long chord bears North 69°47′02″ West, a distance of 195.52 feet to the point of tangency;
                </P>
                <P>
                    <E T="03">Thence,</E>
                     North 44°51′28″ West, a distance of 101.87 feet;
                </P>
                <P>
                    <E T="03">Thence,</E>
                     North 53°50′16″ West, a distance of 200.63 feet;
                </P>
                <P>
                    <E T="03">Thence,</E>
                     North 55°43′04″ West, a distance of 309.84 feet to the 
                    <E T="03">point of beginning.</E>
                </P>
                <P>
                    <E T="03">Basis of Bearings:</E>
                     North 00°00′03″ East, being the bearing from said 
                    <FR>1/4</FR>
                     section corner of sections 2 and 3 to said north 
                    <FR>1/16</FR>
                     section corner of sections 2 and 3.
                </P>
                <P>
                    Meaning and intending to revoke the withdrawal on that portion of the southwest quarter (SW
                    <FR>1/4</FR>
                    ) of the northwest quarter (NW
                    <FR>1/4</FR>
                    ) of section 2 lying northly of said irregular boundary.
                </P>
                <P>The area described contains 31.10 acres in Mesa County.</P>
                <P>2. At 8 a.m. Mountain Time (MT) on January 9, 2024, the land described above will open to the operation of the public land laws, subject to valid existing rights, the provisions of existing withdrawals, other segregations of record, and the requirements of applicable law. All valid applications received at or prior to 8 a.m. MT on January 9, 2024, shall be considered as simultaneously filed at that time. Those received thereafter shall be considered in the order of filing. Appropriation of any of the land referenced in this PLO prior to the date and time of revocation and opening remain unauthorized. The land will remain closed to location and entry under the United States mining laws until such time as the land is conveyed out of Federal control or an opening order is issued pursuant to 43 CFR 2091.6.</P>
                <EXTRACT>
                    <FP>(Authority: 43 U.S.C. 1714)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Robert T. Anderson,</NAME>
                    <TITLE>Solicitor.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00266 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4322-90-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF LABOR</AGENCY>
                <SUBAGY>Occupational Safety and Health Administration</SUBAGY>
                <DEPDOC>[Docket No. OSHA-2012-0005]</DEPDOC>
                <SUBJECT>Standard on Cadmium in General Industries; Extension of the Office of Management and Budget's (OMB) Approval of Information Collection (Paperwork) Requirements</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Occupational Safety and Health Administration (OSHA), Labor.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Request for public comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>OSHA solicits public comments concerning the proposal to extend Office of Management and Budget's (OMB) approval of the information collection requirements specified in the Standard on Cadmium in General Industries.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be submitted (postmarked, sent, or received) by March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P/>
                    <P>
                        <E T="03">Electronically:</E>
                         You may submit comments and attachments electronically at 
                        <E T="03">http://www.regulations.gov,</E>
                         which is the Federal eRulemaking Portal. Follow the instructions online for submitting comments.
                    </P>
                    <P>
                        <E T="03">Docket:</E>
                         To read or download comments or other material in the docket, go to 
                        <E T="03">http://www.regulations.gov.</E>
                         Documents in the docket are listed in the 
                        <E T="03">http://www.regulations.gov</E>
                         index; however, some information (
                        <E T="03">e.g.,</E>
                         copyrighted material) is not publicly available to read or download through the website. All submissions, including copyrighted material, are available for inspection through the OSHA Docket Office. Contact the OSHA Docket Office at (202) 693-2350 (TTY (877) 889-5627) for assistance in locating docket submissions.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions must include the agency name and OSHA docket number OSHA-2012-0005 for the Information Collection Request (ICR). OSHA will place all comments, including any personal information, in the public docket, which may be made available online. Therefore, OSHA cautions interested parties about submitting personal information such as social security numbers and birthdates.
                    </P>
                    <P>
                        For further information on submitting comments, see the “Public Participation” heading in the section of this notice titled 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                        .
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Seleda Perryman or Theda Kenney, 
                        <PRTPAGE P="1128"/>
                        Directorate of Standards and Guidance, OSHA, U.S. Department of Labor; telephone (202) 693-2222.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    The Department of Labor, as part of the continuing effort to reduce paperwork and respondent (
                    <E T="03">i.e.,</E>
                     employer) burden, conducts a preclearance consultation program to provide the public with an opportunity to comment on proposed and continuing information collection requirements in accordance with the Paperwork Reduction Act of 1995 (PRA) (44 U.S.C. 3506(c)(2)(A)). This program ensures that information is in the desired format, reporting burden (time and costs) is minimal, the collection instruments are clearly understood, and OSHA's estimate of the information collection burden is accurate. The Occupational Safety and Health Act of 1970 (OSH Act) (29 U.S.C. 651 
                    <E T="03">et seq.</E>
                    ) authorizes information collection by employers as necessary or appropriate for enforcement of the OSH Act or for developing information regarding the causes and prevention of occupational injuries, illnesses, and accidents (29 U.S.C. 657). The OSH Act also requires that OSHA obtain such information with minimum burden upon employers, especially those operating small businesses, and to reduce to the maximum extent feasible unnecessary duplication of effort in obtaining information (29 U.S.C. 657).
                </P>
                <P>The following sections describe who uses the information collected under each requirement, as well as how they use it. The purpose of these requirements is to protect workers from the health effects associated with occupational exposure to cadmium. Such exposure to cadmium may cause lung cancer, prostate cancer, non-malignant respiratory disease, acute pneumonitis, fever and chest pain, severe weakness, coughing and tightness of the chest, and kidney disease.</P>
                <HD SOURCE="HD1">II. Special Issues for Comment</HD>
                <P>OSHA has a particular interest in comments on the following issues:</P>
                <P>• Whether the proposed information collection requirements are necessary for the proper performance of the agency's functions to protect workers, including whether the information is useful;</P>
                <P>• The accuracy of OSHA's estimate of the burden (time and costs) of the information collection requirements, including the validity of the methodology and assumptions used;</P>
                <P>• The quality, utility, and clarity of the information collected; and</P>
                <P>• Ways to minimize the burden on employers who must comply; for example, by using automated or other technological information collection, and transmission techniques.</P>
                <HD SOURCE="HD1">III. Proposed Actions</HD>
                <P>OSHA is requesting that OMB extend the approval of the information collection requirements contained in the Standard on Cadmium in General Industries (29 CFR 1910.1027). The agency is requesting an adjustment increase of 42,230 (from 73,396 to 115,626 hours). This increase is a result of a computational error discovered in the last ICR. Additionally, OSHA is requesting a decrease in the operation and maintenance costs of $10,114 (from $5,493,656 to $5,483,542). This decrease is a result of a computational error discovered in the last ICR.</P>
                <P>OSHA will summarize the comments submitted in response to this notice and will include this summary in the request to OMB to extend the approval of the information collection requirements.</P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension of a currently approved collection.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Standard on Cadmium in General Industries.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     1218-0185.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Business or other for-profits.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     50,679.
                </P>
                <P>
                    <E T="03">Number of Responses:</E>
                     234,036.
                </P>
                <P>
                    <E T="03">Frequency of Responses:</E>
                     On occasion.
                </P>
                <P>
                    <E T="03">Average Time per Response:</E>
                     Varies.
                </P>
                <P>
                    <E T="03">Estimated Total Burden Hours:</E>
                     115,626.
                </P>
                <P>
                    <E T="03">Estimated Cost (Operation and Maintenance):</E>
                     $5,483,542.
                </P>
                <HD SOURCE="HD1">IV. Public Participation—Submission of Comments on This Notice and internet Access to Comments and Submissions</HD>
                <P>
                    You may submit comments in response to this document as follows: (1) electronically at 
                    <E T="03">http://www.regulations.gov,</E>
                     which is the Federal eRulemaking Portal; (2) by facsimile (fax), if your comments, including attachments, are not longer than 10 pages you may fax them to the OSHA Docket Office at 202-693-1648; or (3) by hard copy. All comments, attachments, and other material must identify the agency name and the OSHA docket number for the ICR OSHA-2012-0005. You may supplement electronic submissions by uploading document files electronically.
                </P>
                <P>
                    Comments and submissions are posted without change at 
                    <E T="03">http://www.regulations.gov.</E>
                     Therefore, OSHA cautions commenters about submitting personal information such as social security numbers and dates of birth. Although all submissions are listed in the 
                    <E T="03">http://www.regulations.gov</E>
                     index, some information (
                    <E T="03">e.g.,</E>
                     copyrighted material) is not publicly available to read or download from this website. All submissions, including copyrighted material, are available for inspection and copying at the OSHA Docket Office. Information on using the 
                    <E T="03">http://www.regulations.gov</E>
                     website to submit comments and access the docket is available at the website's “User Tips” link.
                </P>
                <P>Contact the OSHA Docket Office at (202) 693-2350, (TTY (877) 889-5627) for information about materials not available from the website, and for assistance in using the internet to locate docket submissions.</P>
                <HD SOURCE="HD1">V. Authority and Signature</HD>
                <P>
                    James S. Frederick, Deputy Assistant Secretary of Labor for Occupational Safety and Health, directed the preparation of this notice. The authority for this notice is the Paperwork Reduction Act of 1995 (44 U.S.C. 3506 
                    <E T="03">et seq.</E>
                    ) and Secretary of Labor's Order No. 8-2020 (85 FR 58393).
                </P>
                <SIG>
                    <P>Signed at Washington, DC.</P>
                    <NAME>James S. Frederick,</NAME>
                    <TITLE>Deputy Assistant Secretary of Labor for Occupational Safety and Health.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00199 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4510-26-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF LABOR</AGENCY>
                <SUBAGY>Occupational Safety and Health Administration</SUBAGY>
                <DEPDOC>[Docket No. OSHA-2010-0025]</DEPDOC>
                <SUBJECT>Hydrostatic Testing Provision of the Standard on Portable Fire Extinguishers; Extension of the Office of Management and Budget's (OMB) Approval of Information Collection (Paperwork) Requirements</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Occupational Safety and Health Administration (OSHA), Labor.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Request for public comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>OSHA solicits public comments concerning the proposal to extend the Office of Management and Budget's (OMB) approval of the information collection requirements specified in the Hydrostatic Testing Provision of the Standard on Portable Fire Extinguishers.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be submitted (postmarked, sent, or received) by March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        <PRTPAGE P="1129"/>
                    </P>
                    <P>
                        <E T="03">Electronically:</E>
                         You may submit comments and attachments electronically at 
                        <E T="03">http://www.regualtions.gov,</E>
                         which is the Federal eRulemaking Portal. Follow the instructions online for submitting comments.
                    </P>
                    <P>
                        <E T="03">Docket:</E>
                         To read or download comments or other material in the docket, go to 
                        <E T="03">http://www.regulations.gov.</E>
                         Documents in the docket are listed in the 
                        <E T="03">http://www.regulations.gov</E>
                         index; however, some information (
                        <E T="03">e.g.,</E>
                         copyrighted material) is not publicly available to read or download through the website. All submissions, including copyrighted material, are available for inspection through the OSHA Docket Office. Contact the OSHA Docket Office at (202) 693-2350 (TTY (877) 889-5627) for assistance in locating docket submissions.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions must include the agency name and OSHA docket number (OSHA-2010-0025) for the Information Collection Request (ICR). OSHA will place all comments, including any personal information, in the public docket, which may be made available online. Therefore, OSHA cautions interested parties about submitting personal information such as social security numbers and birthdates.
                    </P>
                    <P>
                        For further information on submitting comments, see the “Public Participation” heading in the section of this notice titled 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                        .
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Seleda Perryman or Theda Kenney, Directorate of Standards and Guidance, OSHA, U.S. Department of Labor; telephone (202) 693-2222.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    The Department of Labor, as part of the continuing effort to reduce paperwork and respondent (
                    <E T="03">i.e.,</E>
                     employer) burden, conducts a preclearance consultation program to provide the public with an opportunity to comment on proposed and continuing information collection requirements in accordance with the Paperwork Reduction Act of 1995 (PRA) (44 U.S.C. 3506(c)(2)(A)). This program ensures that information is in the desired format, reporting burden (time and costs) is minimal, the collection instruments are clearly understood, and OSHA's estimate of the information collection burden is accurate. The Occupational Safety and Health Act of 1970 (OSH Act) (29 U.S.C. 651 
                    <E T="03">et seq.</E>
                    ) authorizes information collection by employers as necessary or appropriate for enforcement of the OSH Act or for developing information regarding the causes and prevention of occupational injuries, illnesses, and accidents (29 U.S.C. 657). The OSH Act also requires that OSHA obtain such information with minimum burden upon employers, especially those operating small businesses, and to reduce to the maximum extent feasible unnecessary duplication of effort in obtaining information (29 U.S.C. 657).
                </P>
                <P>The following sections describe who uses the information collected under each requirement, as well as how they use it.</P>
                <P>The collection of information contained in the Hydrostatic Testing Provision of the Portable Fire Extinguishers Standard are necessary to reduce workers' risk of death or serious injury by ensuring that portable fire extinguishers are in safe operating condition. The following paragraphs describe who uses the information in the testing certification record, as well as how they use it.</P>
                <HD SOURCE="HD2">Test Records (§ 1910.157(f)(16))</HD>
                <P>Paragraph (f)(16) requires employers to develop and maintain a certification record of hydrostatic testing of portable fire extinguishers. The certification record must include the date of inspection, the signature of the person who performed the test, and the serial number (or other identifier) of the fire extinguisher that was tested.</P>
                <HD SOURCE="HD2">Disclosure of Test Certification Records</HD>
                <P>The certification record must be made available to the Assistant Secretary or his/her representative upon request. The certification record provides assurance to employers, workers, and OSHA compliance officers that the fire extinguishers have been hydrostatically tested in accordance with and at the intervals specified in § 1910.157(f)(16), thereby ensuring that they will operate properly in the event workers need to use them. Additionally, these records provide the most efficient means for the compliance officers to determine that an employer is complying with the hydrostatic testing provision.</P>
                <HD SOURCE="HD1">II. Special Issues for Comment</HD>
                <P>OSHA has a particular interest in comments on the following issues:</P>
                <P>• Whether the proposed information collection requirements are necessary for the proper performance of the agency's functions to protect workers, including whether the information is useful;</P>
                <P>• The accuracy of OSHA's estimate of the burden (time and costs) of the information collection requirements, including the validity of the methodology and assumptions used;</P>
                <P>• The quality, utility, and clarity of the information collected; and</P>
                <P>• Ways to minimize the burden on employers who must comply; for example, by using automated or other technological information collection, and transmission techniques.</P>
                <HD SOURCE="HD1">III. Proposed Actions</HD>
                <P>OSHA is requesting that OMB extend the approval of the information collection requirements contained in Hydrostatic Testing Provision of the Standard on Portable Fire Extinguishers. OSHA will retain the current number of burden hours of 504,377 for this Information Collection Request. There are no adjustments or program changes.</P>
                <P>OSHA will summarize the comments submitted in response to this notice and will include this summary in the request to OMB to extend the approval of the information collection requirements.</P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension of a currently approved collection.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Hydrostatic Testing Provision of the Standard on Portable Fire Extinguishers (29 CFR 1910.157(f)(16)).
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     1219-0218.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Business or other for-profits, farms.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     5,869,911.
                </P>
                <P>
                    <E T="03">Number of Responses:</E>
                     5,217,699.
                </P>
                <P>
                    <E T="03">Frequency of Responses:</E>
                     On occasion.
                </P>
                <P>
                    <E T="03">Average Time per Response:</E>
                     Varies.
                </P>
                <P>
                    <E T="03">Estimate Total Burden Hours:</E>
                     504,377.
                </P>
                <P>
                    <E T="03">Estimated Cost (Operation and Maintenance):</E>
                     $210,664,596.
                </P>
                <HD SOURCE="HD1">IV. Public Participation—Submission of Comments on This Notice and Internet Access to Comments and Submissions</HD>
                <P>
                    You may submit comments in response to this document as follows: (1) electronically at 
                    <E T="03">http://www.regulations.gov,</E>
                     which is the Federal eRulemaking Portal; (2) by facsimile (fax), if your comments, including attachments, are not longer than 10 pages you may fax them to the OSHA Docket Office at 202-693-1648; or (3) by hard copy. All comments, attachments, and other material must identify the agency name and the OSHA docket number for the ICR (OSHA-1218-0218). You may supplement electronic submissions by uploading document files electronically.
                </P>
                <P>
                    Comments and submissions are posted without change at 
                    <E T="03">http://www.regulation.gov.</E>
                     Therefore, OSHA cautions commenters about submitting personal information such as social security numbers and dates of birth. Although all submissions are listed in 
                    <PRTPAGE P="1130"/>
                    the 
                    <E T="03">http://www.regulations.gov</E>
                     index, some information (
                    <E T="03">e.g.,</E>
                     copyrighted material) is not publicly available to read or download from this website. All submissions, including copyrighted material, are available for inspection and copying at the OSHA Docket Office. Information on using the 
                    <E T="03">http://www.regulations.gov</E>
                     website to submit comments and access the docket is available at the website's “User Tips” link. Contact the OSHA Docket Office at (202) 693-2350, (TTY (877) 889-5627) for information about materials not available from the website, and for assistance in using the internet to locate docket submissions.
                </P>
                <HD SOURCE="HD1">V. Authority and Signature</HD>
                <P>
                    James S. Frederick, Deputy Assistant Secretary of Labor for Occupational Safety and Health, directed the preparation of this notice. The authority for this notice is the Paperwork Reduction Act of 1995 (44 U.S.C. 3506 
                    <E T="03">et seq.</E>
                    ) and Secretary of Labor's Order No. 8-2020 (85 FR 58393).
                </P>
                <SIG>
                    <P>Signed at Washington, DC.</P>
                    <NAME>James S. Frederick,</NAME>
                    <TITLE>Deputy Assistant Secretary of Labor for Occupational Safety and Health.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00198 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4510-26-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">NATIONAL AERONAUTICS AND SPACE ADMINISTRATION</AGENCY>
                <DEPDOC>[NOTICE: 24-002]</DEPDOC>
                <SUBJECT>Name of Information Collection: NASA Special Events</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Aeronautics and Space Administration (NASA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of information collection.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The National Aeronautics and Space Administration, 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 proposed and/or continuing information collections.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments are due by March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Written comments and recommendations for this information collection should be sent within 60 days of publication of this notice to 
                        <E T="03">www.reginfo.gov/public/do/PRAMain.</E>
                    </P>
                    <P>Find this particular information collection by selecting “Currently under 60-day Review—Open for Public Comments” or by using the search function.</P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Requests for additional information or copies of the information collection instrument(s) and instructions should be directed to NASA PRA Clearance Officer, Bill Edwards-Bodmer, NASA Headquarters, 300 E Street SW, JF0000, Washington, DC 20546, phone 757-864-7998, or email 
                        <E T="03">hq-ocio-pra-program@mail.nasa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Abstract</HD>
                <P>The National Aeronautics and Space Administration (NASA) is committed to effectively performing the Agency's communication function in accordance with the Space Act section 203(a)(3) to “provide for the widest practicable and appropriate dissemination of information concerning its activities and the results there of,” and to enhance public understanding of, and participation in, the nation's space program in accordance with the NASA Strategic Plan. The Space Act of 1958, directs the Agency to expand human knowledge of Earth and space phenomena. Organizing outreach events is one way NASA intends to leverage excitement about the nation's space program and expand human knowledge of Earth and space phenomena. In order to organize effective outreach events and registration opportunities for members of the public, it is necessary to collect information from perspective guests and those that will check-in the guests at events. The NASA Special Events System is a tool to allow invitees to register for and check-in to NASA event opportunities (launch viewing, agency engagements, etc.) in a single location.</P>
                <HD SOURCE="HD1">II. Methods of Collection</HD>
                <P>The NASA Special Events tool is a web-based application on a Salesforce platform that enables the NASA OCOMM team to manage guest information, communication, and reporting agency-wide. The intent of using electronic collection techniques is to increase the accuracy of information gathered and to streamline the process for guests and workforce alike.</P>
                <HD SOURCE="HD1">III. Data</HD>
                <P>
                    <E T="03">Title:</E>
                     NASA Special Events.
                </P>
                <P>
                    <E T="03">OMB Number:</E>
                     TBA.
                </P>
                <P>
                    <E T="03">Type of review:</E>
                     New Information Collection.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     10,000 NASA Invited Guests.
                </P>
                <P>
                    <E T="03">Estimated Annual Number of Activities:</E>
                     15.
                </P>
                <P>
                    <E T="03">Estimated Number of Respondents per Activity:</E>
                     650.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     10,000.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     10 Minutes.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Burden Hours:</E>
                     1,667 Hours.
                </P>
                <HD SOURCE="HD1">IV. Request for Comments</HD>
                <P>
                    <E T="03">Comments are invited on:</E>
                     (1) Whether the proposed collection of information is necessary for the proper performance of the functions of NASA, including whether the information collected has practical utility; (2) the accuracy of NASA's estimate of the burden (including hours and cost) of the proposed collection of information; (3) ways to enhance the quality, utility, and clarity of the information to be collected; and (4) ways to minimize the burden of the collection of information on respondents, including automated collection techniques or the use of other forms of information technology.
                </P>
                <P>Comments submitted in response to this notice will be summarized and included in the request for OMB approval of this information collection. They will also become a matter of public record.</P>
                <SIG>
                    <NAME>William Edwards-Bodmer,</NAME>
                    <TITLE>NASA PRA Clearance Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00165 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7510-13-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">NATIONAL CREDIT UNION ADMINISTRATION</AGENCY>
                <SUBJECT>Revisions of Agency Information Collections for Comments Request: Proposed Collections</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Credit Union Administration (NCUA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice and request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The National Credit Union Administration (NCUA) will submit the following information collection requests to the Office of Management and Budget (OMB) for review and clearance in accordance with the Paperwork Reduction Act of 1995, on or after the date of publication of this notice.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Written comments should be received on or before March 11, 2024 to be assured consideration.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Interested persons are invited to submit written comments on the information collection to Mahala Vixamar, National Credit Union Administration, 1775 Duke Street, Alexandria, Virginia 22314, Suite 5067; Fax No. 703-519-8579; or Email at 
                        <E T="03">PRAComments@NCUA.gov</E>
                        .
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Copies of the submission may be obtained by contacting Mahala Vixamar at (703) 718-1155.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <PRTPAGE P="1131"/>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">OMB Number:</E>
                     3133-0102.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Truth in Lending (TILA); Regulation Z.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension of a previously approved collection.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     The Truth in Lending Act (TILA) was enacted to foster comparison credit shopping and informed credit decision making by requiring accurate disclosure of the costs and terms of credit to consumers and to protect consumers against inaccurate and unfair credit billing practices. TILA has been revised numerous times since it took effect, notably by passage of the Fair Credit Billing Act of 1974, the Consumer Leasing Act of 1976, the Truth in Lending Simplification and Reform Act of 1980, the Fair Credit and Charge Card Disclosure Act of 1988, and the Home Equity Loan Consumer Protection Act of 1988. Historically, TILA was implemented by the Board of Governors of the Federal Reserve System's (FRB) Regulation Z, 12 CFR part 226. The Dodd-Frank Wall Street Reform and Consumer Protection Act transferred FRB's rulemaking authority for TILA to the Consumer Financial Protection Bureau (CFPB).
                </P>
                <P>Regulation Z contains several provisions that impose information collection requirements: The information collection requirements for open-end credit products; the information collection requirements for closed-end credit; the information collection requirements that apply to both open- and closed-end mortgage credit; the information collection requirements for specific residential mortgage types-namely, reverse mortgages and high cost mortgages with rates and fees above specified thresholds; the information collection requirements for private education loans; and information collection requirements related to Regulation Z's advertising and record retention rules.</P>
                <P>The collection of information pursuant to Part 1026 is triggered by specific events and disclosures and must be provided to consumers within the time periods established under the regulation. To ease the compliance cost (particularly for small credit unions), model forms and clauses are appended to the regulation.</P>
                <P>
                    <E T="03">Affected Public:</E>
                     Private Sector: Not-for-profit institutions.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Burden Hours:</E>
                     2,906,986.
                </P>
                <P>
                    <E T="03">OMB Number:</E>
                     3133-0180.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Liquidity and Contingency Funding Plans, 12 CFR 741.12.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension of a previously approved collection.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     Section 741.12 establishes a three-tier framework for FICUs, based on asset size. FICUs with assets under $50 million must maintain a basic policy, those with assets of $50 million and over must maintain a contingency funding plan, and those with assets over $250 million must maintain a contingency funding plan and establish a federal liquidity contingency source. The reviews will conclude if federally insured credit unions are maintaining appropriate liquidity levels for the amount of balance sheet risk exposure and help prevent losses to credit unions and the NCUSIF.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Private Sector: Not-for-profit institutions.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Burden Hours:</E>
                     4,248.
                </P>
                <P>
                    <E T="03">OMB Number:</E>
                     3133-0186.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Higher-Risk Mortgage Appraisals.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Revision of a currently approved collection.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     Section 1471 of the Dodd-Frank Act established Truth in Lending section 129H, which contains appraisal requirements applicable to higher-risk mortgages and prohibits a creditor from extending credit in the form of a higher-risk mortgage loan to any consumer without meeting those requirements. A higher-risk mortgage is defined as a residential mortgage loan secured by a principal dwelling with an annual percentage rate that exceeds the average prime offer rate for a comparable transaction as of the date the interest rate is set by certain enumerated percentage point spreads. This statutory requirement is promulgated in 12 CFR part 1026, Regulation Z, by the Bureau of Consumer Financial Protection, the Board of Governors of the Federal Reserve, the Federal Deposit Insurance Corporation, the Federal Housing Finance Authority, the NCUA, and the Office of the Comptroller of the Currency. The information collections are required by statute, are necessary to protect consumers, and promote the safety and soundness of creditors making higher-risk mortgage loans.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Private Sector: Not-for-profit institutions.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Burden Hours:</E>
                     236.
                </P>
                <P>
                    <E T="03">Request for Comments:</E>
                     Comments submitted in response to this notice will be summarized and included in the request for Office of Management and Budget approval. All comments will become a matter of public record. The public is invited to submit comments concerning: (a) whether the collection of information is necessary for the proper performance of the function of the agency, including whether the information will have practical utility; (b) the accuracy of the agency's estimate of the burden of the collection of information, including the validity of the methodology and assumptions used; (c) ways to enhance the quality, utility, and clarity of the information to be collected; and (d) ways to minimize the burden of the collection of the information on the respondents, including the use of automated collection techniques or other forms of information technology.
                </P>
                <SIG>
                    <P>By the National Credit Union Administration Board.</P>
                    <NAME>Melane Conyers-Ausbrooks,</NAME>
                    <TITLE>Secretary of the Board.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00182 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7535-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">PENSION BENEFIT GUARANTY CORPORATION</AGENCY>
                <SUBJECT>Submission of Information Collection for OMB Review; Comment Request; Disclosure of Termination Information</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Pension Benefit Guaranty Corporation.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of request for extension of OMB approval of an information collection.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Pension Benefit Guaranty Corporation (PBGC) is requesting that the Office of Management and Budget (OMB) extend approval under the Paperwork Reduction Act of a collection of information on the disclosure of termination information under its regulations for distress terminations and for PBGC-initiated terminations. This notice informs the public of PBGC's intent and solicits public comment on the collection of information.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be submitted on or before February 8, 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 by selecting “Currently under 30-day Review—Open for Public Comments” or by using the search function.
                    </P>
                    <P>
                        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>
                    <PRTPAGE P="1132"/>
                    <P>
                        A copy of the request will be posted on PBGC's website at 
                        <E T="03">https://www.pbgc.gov/prac/laws-and-regulation/federal-register-notices-open-for-comment.</E>
                         It may also be obtained without charge by writing to the Disclosure Division (
                        <E T="03">disclosure@pbgc.gov</E>
                        ), Office of the General Counsel of PBGC, 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. 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>Sections 4041 and 4042 of the Employee Retirement Income Security Act of 1974, as amended (“ERISA”), 29 U.S.C. 13019-1461, govern the termination of single-employer defined benefit pension plans that are subject to title IV of ERISA. A plan administrator may initiate a distress termination pursuant to section 4041(c), and PBGC may itself initiate proceedings to terminate a pension plan under section 4042 if PBGC determines that certain conditions are present. Under sections 4041 and 4042 of ERISA, upon a request by an affected party, a plan administrator must disclose information it has submitted to PBGC in connection with a distress termination filing, and a plan administrator or plan sponsor must disclose information it has submitted to PBGC in connection with a PBGC-initiated termination. The provisions also require PBGC to disclose the administrative record relating to a PBGC-initiated termination upon request by an affected party.</P>
                <P>
                    The existing collection of information was approved under OMB control number 1212-0065 (expires April 30, 2024). On October 27, 2023, PBGC published in the 
                    <E T="04">Federal Register</E>
                     (at 88 FR 73887) a notice informing the public of its intent to request an extension of this collection of information. No comments were received. PBGC is requesting that OMB extend approval of the collection 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 approximately 30 plans will terminate as distress or PBGC-initiated terminations each year and that two participants or other affected parties of every nine distress terminations or PBGC-initiated terminations filed will annually make requests for termination information, or 
                    <FR>2/9</FR>
                     of 30 (approximately 7 per year). PBGC estimates that the hour burden for each request will be about 20 hours. PBGC expects that the staff of plan administrators and sponsors will perform the work in-house and that no work will be contracted to third parties. The total annual hour burden is estimated to be 140 hours (7 plans × 20 hours), and the total annual cost burden is estimated to be $0.
                </P>
                <SIG>
                    <P>Issued in Washington, DC.</P>
                    <NAME>Hilary Duke,</NAME>
                    <TITLE>Assistant General Counsel for Regulatory Affairs, Pension Benefit Guaranty Corporation.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00188 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7709-02-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[Release No. 34-99266; File No. SR-MEMX-2023-41]</DEPDOC>
                <SUBJECT>Self-Regulatory Organizations; MEMX LLC; Notice of Filing and Immediate Effectiveness of a Proposed Rule Change To Amend the Exchange's Fee Schedule To Remove Expired Rebate Tier Criterion</SUBJECT>
                <DATE>January 3, 2024.</DATE>
                <P>
                    Pursuant to Section 19(b)(1) of the Securities Exchange Act of 1934 (the “Act”),
                    <SU>1</SU>
                    <FTREF/>
                     and Rule 19b-4 thereunder,
                    <SU>2</SU>
                    <FTREF/>
                     notice is hereby given that on December 26, 2023, MEMX LLC (“MEMX” or the “Exchange”) filed with the Securities and Exchange Commission (the “Commission”) the proposed rule change as described in Items I, II, and III below, which Items have been prepared by the Exchange. 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>
                <HD SOURCE="HD1">I. Self-Regulatory Organization's Statement of the Terms of Substance of the Proposed Rule Change</HD>
                <P>
                    The Exchange is filing with the Commission a proposed rule change to amend the Exchange's fee schedule applicable to Members 
                    <SU>3</SU>
                    <FTREF/>
                     (the “Fee Schedule”) pursuant to Exchange Rules 15.1(a) and (c). The Exchange proposes to implement the changes to the Fee Schedule pursuant to this proposal on January 1, 2024. The text of the proposed rule change is provided in Exhibit 5.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">See</E>
                         Exchange Rule 1.5(p).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">II. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <P>In its filing with the Commission, the Exchange included statements concerning the purpose of and basis for the proposed rule change and discussed any comments it received on the proposed rule change. The text of these statements may be examined at the places specified in Item IV below. The Exchange has prepared summaries, set forth in sections A, B, and C below, of the most significant aspects of such statements.</P>
                <HD SOURCE="HD2">A. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <HD SOURCE="HD3">1. Purpose</HD>
                <P>The purpose of the proposed rule change is to amend the Fee Schedule to remove an expired criteria under Liquidity Provision Tier 4.</P>
                <P>
                    The Exchange currently provides a base rebate of $0.0015 per share for executions of orders in securities priced at or above $1.00 per share that add displayed liquidity to the Exchange (such orders, “Added Displayed Volume”).
                    <SU>4</SU>
                    <FTREF/>
                     The Exchange also currently offers Liquidity Provision Tiers 1-5 under which a Member may receive an enhanced rebate for executions of Added Displayed Volume by achieving the corresponding required volume criteria for each such tier. With respect to Liquidity Provision Tier 4, the Exchange currently provides an enhanced rebate of $0.0029 per share for executions of Added Displayed Volume for Members that qualify for such tier by achieving: (1) an ADAV 
                    <SU>5</SU>
                    <FTREF/>
                     (excluding Retail Orders) that is equal to or greater than 0.09% of the TCV; 
                    <SU>6</SU>
                    <FTREF/>
                     or (2) an ADAV that is equal to or greater than 0.006% of the TCV and a Step-Up 
                    <PRTPAGE P="1133"/>
                    ADAV 
                    <SU>7</SU>
                    <FTREF/>
                     from June 2023 that is equal to or greater than 40% of the Member's June 2023 ADAV.
                    <SU>8</SU>
                    <FTREF/>
                     Additionally, the Fee Schedule indicates that criteria (2) of Liquidity Provision Tier 4 will expire no later than December 31, 2023. Now, given the expiration of criteria (2) of Liquidity Provision Tier 4, it is necessary to modify the Fee Schedule to delete this criteria (2) as well as the note under the Liquidity Provision Tiers pricing table that indicates its expiration, as both are no longer applicable and otherwise obsolete. The Exchange is not proposing to make any changes to this or any other Liquidity Provision Tier, and as such, Liquidity Provision Tier 4 will now consist solely of the previously existing criteria (1).
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         The base rebate for executions of Added Displayed Volume is referred to by the Exchange on the Fee Schedule under the existing description “Added displayed volume” with a Fee Code of “B”, “D” or “J”, as applicable, on execution reports.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         As set forth on the Fee Schedule, “ADAV” means the average daily added volume calculated as the number of shares added per day, which is calculated on a monthly basis.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         As set forth on the Fee Schedule, “TCV” means total consolidated volume calculated as the volume reported by all exchanges and trade reporting facilities to a consolidated transaction reporting plan for the month for which the fees apply.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         As set forth on the Fee Schedule, “Step Up ADAV” means ADAV in the relevant baseline month subtracted from current ADAV.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         The proposed pricing for Liquidity Provision Tier 4 is referred to by the Exchange on the Fee Schedule under the existing description “Added displayed volume, Liquidity Provision Tier 4” with a Fee Code of “B4”, “D4” or “J4”, as applicable, to be provided by the Exchange on the monthly invoices provided to Members.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">2. Statutory Basis</HD>
                <P>
                    The Exchange believes that the proposed rule change is consistent with the provisions of Section 6 of the Act,
                    <SU>9</SU>
                    <FTREF/>
                     in general, and with Sections 6(b)(4) and 6(b)(5) of the Act,
                    <SU>10</SU>
                    <FTREF/>
                     in particular, in that it provides for the equitable allocation of reasonable dues, fees and other charges among its Members and other persons using its facilities and is not designed to permit unfair discrimination between customers, issuers, brokers, or dealers.
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         15 U.S.C. 78f.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         15 U.S.C. 78f(b)(4) and (5).
                    </P>
                </FTNT>
                <P>The Exchange believes that the proposed change to modify Liquidity Provision Tier 4 to remove the expired criteria (2) criteria is reasonable because there was an expiration date associated with this criteria that has now passed. As such, this criteria is no longer available under this tier, and should not remain on the Fee Schedule. The Exchange believes that the enhanced rebate for executions of Added Displayed Volume provided under Liquidity Provision Tier 4, which the Exchange is not proposing to change with this proposal, remains commensurate with the required criteria under such tier, as modified, and is reasonably related to the market quality benefits that such tier is designed to achieve. The Exchange also believes the enhanced rebate for executions of Added Displayed Volume provided under Liquidity Provision Tier 4 remains equitable and not unfairly discriminatory, as such enhanced rebate will continue to apply equally to all qualifying Members.</P>
                <P>
                    For the reasons discussed above, the Exchange submits that the proposal satisfies the requirements of Sections 6(b)(4) and 6(b)(5) of the Act 
                    <SU>11</SU>
                    <FTREF/>
                     in that it provides for the equitable allocation of reasonable dues, fees and other charges among its Members and other persons using its facilities and is not designed to unfairly discriminate between customers, issuers, brokers, or dealers.
                </P>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         15 U.S.C. 78f(b)(4) and (5).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">B. Self-Regulatory Organization's Statement on Burden on Competition</HD>
                <P>
                    In accordance with Section 6(b)(8) of the Act,
                    <SU>12</SU>
                    <FTREF/>
                     the Exchange believes that the proposed rule change will not impose any burden on competition that is not necessary or appropriate in furtherance of the purposes of the Act.
                </P>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         15 U.S.C. 78f(b)(8).
                    </P>
                </FTNT>
                <P>The Exchange believes that the proposed rule change would not place any burden on competition that is not necessary or appropriate in furtherance of the purposes of the Act. The proposed rule change is not designed to address any competitive issues but rather is designed to enhance the clarity of the Fee Schedule and alleviate possible Member confusion that may arise from the inclusion of obsolete language.</P>
                <HD SOURCE="HD2">C. Self-Regulatory Organization's Statement on Comments on the Proposed Rule Change Received From Members, Participants, or Others</HD>
                <P>The Exchange neither solicited nor received comments on the proposed rule change.</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)(ii) of the Act 
                    <SU>13</SU>
                    <FTREF/>
                     and Rule 19b-4(f)(2) 
                    <SU>14</SU>
                    <FTREF/>
                     thereunder.
                </P>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         15 U.S.C. 78s(b)(3)(A)(ii).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         17 CFR 240.19b-4(f)(2).
                    </P>
                </FTNT>
                <P>At any time within 60 days of the filing of the proposed rule change, the Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is necessary or appropriate in the public interest, for the protection of investors, or otherwise in furtherance of the purposes of the Act. If the Commission takes such action, the Commission shall institute proceedings to determine whether the proposed rule change should be approved or disapproved.</P>
                <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">https://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-MEMX-2023-41 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-1090.</P>
                <FP>
                    All submissions should refer to file number SR-MEMX-2023-41. 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">https://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 a.m. and 3 p.m. Copies of the filing also will be available for inspection and copying at the principal office of the Exchange. 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-MEMX-2023-41 and should be submitted on or before January 30, 2024.
                </FP>
                <SIG>
                    <PRTPAGE P="1134"/>
                    <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-00178 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[Release No. 34-99269; File No. SR-NASDAQ-2023-056]</DEPDOC>
                <SUBJECT>Self-Regulatory Organizations; The Nasdaq Stock Market LLC; Notice of Filing and Immediate Effectiveness of Proposed Rule Change To Amend the Exchange's Schedule of Fees at Equity 7 Sections 114 and 118</SUBJECT>
                <DATE>January 3, 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 December 21, 2023, The Nasdaq Stock Market LLC (“Nasdaq” or “Exchange”) 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 Exchange. 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>
                <HD SOURCE="HD1">I. Self-Regulatory Organization's Statement of the Terms of Substance of the Proposed Rule Change</HD>
                <P>The Exchange proposes to amend the Exchange's schedule of fees at Equity 7, Sections 114 and 118.</P>
                <P>
                    The text of the proposed rule change is available on the Exchange's website at 
                    <E T="03">https://listingcenter.nasdaq.com/rulebook/nasdaq/rules,</E>
                     at the principal office of the Exchange, and at the Commission's Public Reference Room.
                </P>
                <HD SOURCE="HD1">II. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <P>In its filing with the Commission, the Exchange included statements concerning the purpose of and basis for the proposed rule change and discussed any comments it received on the proposed rule change. The text of these statements may be examined at the places specified in Item IV below. The Exchange has prepared summaries, set forth in sections A, B, and C below, of the most significant aspects of such statements.</P>
                <HD SOURCE="HD2">A. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <HD SOURCE="HD3">1. Purpose</HD>
                <P>On December 13, 2023, Nasdaq experienced a technical issue with its RASH order handling system. The issue involved a duplication of an internal order identification numbers, which impacted a subset of orders for some members, including unacknowledged orders, an inability to cancel open orders, intermittent port disconnects, missing execution reports, and mismatched execution reports.</P>
                <P>Because Nasdaq's fee and rebate schedule in Equity 7, Sections 114 and 118 provide that members may achieve better pricing if they achieve certain specified volumes of activity during a given month (as measured by Consolidated Volume (defined below) and Average Daily Volume (“ADV”)), the RASH issue may have impacted the ability of affected members to reach the required volumes. By way of illustration, a member with shares of liquidity provided in all securities through one of its Nasdaq Market Center market participant identifiers (“MPIDs”) that represent more than 1.50% of the total consolidated volume reported to all consolidated transaction reporting plans by all exchanges and trade reporting facilities in equity securities of at least one round lot (“Consolidated Volume”) during a month receives a rebate of $0.00305 per share executed with respect to liquidity that it provides during the month through displayed quotes/orders. By contrast, members providing lower volumes of liquidity receive lower rebates with respect to displayed quotes/order ranging from $0.0020 to $0.0030 per share executed. If a member had provided liquidity that represented slightly in excess of 1.50% of Consolidated Volume on each day of December 2023 other than December 13, but was prevented from reaching comparable levels on that date due to the RASH issue, it is possible that the rebate it would ultimately earn for the entire month would be lower than would otherwise have been the case. Similarly, under Equity 7, Section 114, a member may be entitled to receive an enhanced rebate under Nasdaq's Qualified Market Maker Program, Designated Liquidity Provider Program, or its NBBO Program, based on its achievement of certain Consolidated Volume or ADV criteria specified in the rule. The ability of a member to achieve these criteria may have also been affected by the RASH issue.</P>
                <P>Accordingly, in order to ensure that fees and rebates are not adversely impacted by the RASH issue, Nasdaq proposes to exclude December 13, 2023 from calculations of Consolidated Volume and ADV made under Equity 7, Sections 114 and 118 if doing so would allow a member to achieve more favorable pricing than would be the case if the day were included. Thus, members that are unaffected by the RASH issue would not have the day arbitrarily excluded from their calculations. Nasdaq will perform all calculations needed to implement the change.</P>
                <HD SOURCE="HD3">2. Statutory Basis</HD>
                <P>
                    The Exchange believes that its proposal is consistent with Section 6(b) of the Act,
                    <SU>3</SU>
                    <FTREF/>
                     in general, and furthers the objectives of Sections 6(b)(4) and 6(b)(5) of the Act,
                    <SU>4</SU>
                    <FTREF/>
                     in particular, in that it provides for the equitable allocation of reasonable dues, fees and other charges among members and issuers and other persons using any facility, and is not designed to permit unfair discrimination between customers, issuers, brokers, or dealers.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         15 U.S.C. 78f(b).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         15 U.S.C. 78f(b)(4) and (5).
                    </P>
                </FTNT>
                <P>Nasdaq believes that the proposed change is reasonable because it will allow members to receive December 2023 pricing that is based on either the exclusion, or the inclusion, of December 13, whichever is more favorable to the member. The proposed change is equitable and not unfairly discriminatory, because it will ensure that the fees and rebates applicable to members that were subject to the RASH issue are not adversely affected by the issue.</P>
                <HD SOURCE="HD2">B. Self-Regulatory Organization's Statement on Burden on Competition</HD>
                <P>
                    The Exchange does not believe that the proposed rule change will impose any burden on competition not necessary or appropriate in furtherance of the purposes of the Act. The change will help to ensure that members that were affected by the RASH issue are not required to pay higher fees, or receive lower rebates, during December 2023 than would otherwise be the case. Accordingly, Nasdaq believes that the proposed changes will protect members from incurring unanticipated charges.
                    <PRTPAGE P="1135"/>
                </P>
                <HD SOURCE="HD2">C. Self-Regulatory Organization's Statement on Comments on the Proposed Rule Change Received From Members, Participants, or Others</HD>
                <P>No written comments were either solicited or 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)(ii) of the Act.
                    <SU>5</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         15 U.S.C. 78s(b)(3)(A)(ii).
                    </P>
                </FTNT>
                <P>At any time within 60 days of the filing of the proposed rule change, the Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is: (i) necessary or appropriate in the public interest; (ii) for the protection of investors; or (iii) otherwise in furtherance of the purposes of the Act. If the Commission takes such action, the Commission shall institute proceedings to determine whether the proposed rule should be approved or disapproved.</P>
                <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">https://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-NASDAQ-2023-056 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-1090.</P>
                <FP>
                    All submissions should refer to file number SR-NASDAQ-2023-056. 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">https://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 a.m. and 3 p.m. Copies of the filing also will be available for inspection and copying at the principal office of the Exchange. 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-NASDAQ-2023-056 and should be submitted on or before January 30, 2024.
                    <FTREF/>
                </FP>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         17 CFR 200.30-3(a)(12).
                    </P>
                </FTNT>
                <SIG>
                    <P>
                        For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
                        <SU>6</SU>
                    </P>
                    <NAME>Sherry R. Haywood,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00179 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[Release No. 34-99270; File No. SR-BX-2023-034]</DEPDOC>
                <SUBJECT>Self-Regulatory Organizations; Nasdaq BX, Inc.; Notice of Filing and Immediate Effectiveness of Proposed Rule Change To Amend the Exchange's Schedule of Fees at Equity 7, Section 118</SUBJECT>
                <DATE>January 3, 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 December 21, 2023, Nasdaq BX, Inc. (“BX” or “Exchange”) 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 Exchange. 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>
                <HD SOURCE="HD1">I. Self-Regulatory Organization's Statement of the Terms of Substance of the Proposed Rule Change</HD>
                <P>The Exchange proposes to amend the Exchange's schedule of fees at Equity 7, Section 118.</P>
                <P>
                    The text of the proposed rule change is available on the Exchange's website at 
                    <E T="03">https://listingcenter.nasdaq.com/rulebook/bx/rules,</E>
                     at the principal office of the Exchange, and at the Commission's Public Reference Room.
                </P>
                <HD SOURCE="HD1">II. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <P>In its filing with the Commission, the Exchange included statements concerning the purpose of and basis for the proposed rule change and discussed any comments it received on the proposed rule change. The text of these statements may be examined at the places specified in Item IV below. The Exchange has prepared summaries, set forth in sections A, B, and C below, of the most significant aspects of such statements.</P>
                <HD SOURCE="HD2">A. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <HD SOURCE="HD3">1. Purpose</HD>
                <P>On December 13, 2023, BX experienced a technical issue with its RASH order handling system. The issue involved a duplication of an internal order identification numbers, which impacted a subset of orders for some members, including unacknowledged orders, an inability to cancel open orders, intermittent port disconnects, missing execution reports, and mismatched execution reports.</P>
                <P>
                    Because BX's fee and rebate schedule in Equity 7, Section 118 provide that members may achieve better pricing if they achieve certain specified volumes of activity during a given month (as measured by Consolidated Volume (defined below) and Average Daily Volume (“ADV”)), the RASH issue may have impacted the ability of affected members to reach the required volumes. By way of illustration, a member with shares of liquidity provided in all securities through one of its market participant identifiers (“MPIDs”) that represent more than 0.50% [sic] of the total consolidated volume reported to all consolidated transaction reporting plans by all exchanges and trade reporting facilities in equity securities of at least one round lot (“Consolidated Volume”) during a month is charged a fee of $0.0020 per share executed with respect to liquidity that it provides during the month through displayed orders. By contrast, members providing lower volumes of liquidity pay a higher fee of $0.0030 per share executed. If a member had provided liquidity that 
                    <PRTPAGE P="1136"/>
                    represented slightly in excess of 0.50% [sic] of Consolidated Volume on each day of December 2023 other than December 13, but was prevented from reaching comparable levels on that date due to the RASH issue, it is possible that the rebate it would ultimately earn for the entire month would be lower than would otherwise have been the case. Similarly, a member may be entitled to receive an enhanced rebate under BX's Qualified Market Maker Program or its Retail Price Improvement Program, based on its achievement of certain Consolidated Volume or ADV criteria specified in the rule. The ability of a member to achieve these criteria may have also been affected by the RASH issue.
                </P>
                <P>Accordingly, in order to ensure that fees and rebates are not adversely impacted by the RASH issue, BX proposes to exclude December 13, 2023 from calculations of Consolidated Volume and ADV made under Equity 7, Section 118 if doing so would allow a member to achieve more favorable pricing than would be the case if the day were included. Thus, members that are unaffected by the RASH issue would not have the day arbitrarily excluded from their calculations. BX will perform all calculations needed to implement the change.</P>
                <HD SOURCE="HD3">2. Statutory Basis</HD>
                <P>
                    The Exchange believes that its proposal is consistent with Section 6(b) of the Act,
                    <SU>3</SU>
                    <FTREF/>
                     in general, and furthers the objectives of Sections 6(b)(4) and 6(b)(5) of the Act,
                    <SU>4</SU>
                    <FTREF/>
                     in particular, in that it provides for the equitable allocation of reasonable dues, fees and other charges among members and issuers and other persons using any facility, and is not designed to permit unfair discrimination between customers, issuers, brokers, or dealers.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         15 U.S.C. 78f(b).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         15 U.S.C. 78f(b)(4) and (5).
                    </P>
                </FTNT>
                <P>BX believes that the proposed change is reasonable because it will allow members to receive December 2023 pricing that is based on either the exclusion, or the inclusion, of December 13, whichever is more favorable to the member. The proposed change is equitable and not unfairly discriminatory, because it will ensure that the fees and rebates applicable to members that were subject to the RASH issue are not adversely affected by the issue.</P>
                <HD SOURCE="HD2">B. Self-Regulatory Organization's Statement on Burden on Competition</HD>
                <P>The Exchange does not believe that the proposed rule change will impose any burden on competition not necessary or appropriate in furtherance of the purposes of the Act. The change will help to ensure that members that were affected by the RASH issue are not required to pay higher fees, or receive lower rebates, during December 2023 than would otherwise be the case. Accordingly, BX believes that the proposed changes will protect members from incurring unanticipated charges.  </P>
                <HD SOURCE="HD2">C. Self-Regulatory Organization's Statement on Comments on the Proposed Rule Change Received From Members, Participants, or Others</HD>
                <P>No written comments were either solicited or 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)(ii) of the Act.
                    <SU>5</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         15 U.S.C. 78s(b)(3)(A)(ii).
                    </P>
                </FTNT>
                <P>At any time within 60 days of the filing of the proposed rule change, the Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is: (i) necessary or appropriate in the public interest; (ii) for the protection of investors; or (iii) otherwise in furtherance of the purposes of the Act. If the Commission takes such action, the Commission shall institute proceedings to determine whether the proposed rule should be approved or disapproved.</P>
                <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">https://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-BX-2023-034 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-1090.</P>
                <FP>
                    All submissions should refer to file number SR-BX-2023-034. 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">https://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 a.m. and 3 p.m. Copies of the filing also will be available for inspection and copying at the principal office of the Exchange. 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-BX-2023-034 and should be submitted on or before January 30, 2024.
                </FP>
                <SIG>
                    <P>
                        For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
                        <SU>6</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>6</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-00176 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[Release No. 34-99268; File No. SR-Phlx-2023-58]</DEPDOC>
                <SUBJECT>Self-Regulatory Organizations; Nasdaq PHLX LLC; Notice of Filing and Immediate Effectiveness of Proposed Rule Change To Amend the Exchange's Schedule of Fees at Equity 7, Section 3</SUBJECT>
                <DATE>January 3, 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 December 21, 2023, Nasdaq PHLX LLC (“PHLX” or “Exchange”) filed with the Securities and Exchange Commission (“Commission”) the proposed rule change as described in Items I, II, and 
                    <PRTPAGE P="1137"/>
                    III, below, which Items have been prepared by the Exchange. 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>
                <HD SOURCE="HD1">I. Self-Regulatory Organization's Statement of the Terms of Substance of the Proposed Rule Change</HD>
                <P>The Exchange proposes to amend the Exchange's schedule of fees at Equity 7, Section 3.</P>
                <P>
                    The text of the proposed rule change is available on the Exchange's website at 
                    <E T="03">https://listingcenter.nasdaq.com/rulebook/phlx/rules,</E>
                     at the principal office of the Exchange, and at the Commission's Public Reference Room.
                </P>
                <HD SOURCE="HD1">II. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <P>In its filing with the Commission, the Exchange included statements concerning the purpose of and basis for the proposed rule change and discussed any comments it received on the proposed rule change. The text of these statements may be examined at the places specified in Item IV below. The Exchange has prepared summaries, set forth in sections A, B, and C below, of the most significant aspects of such statements.</P>
                <HD SOURCE="HD2">A. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <HD SOURCE="HD3">1. Purpose</HD>
                <P>On December 13, 2023, PHLX experienced a technical issue with its RASH order handling system. The issue involved a duplication of an internal order identification numbers, which impacted a subset of orders for some members, including unacknowledged orders, an inability to cancel open orders, intermittent port disconnects, missing execution reports, and mismatched execution reports.</P>
                <P>Because PHLX's fee and rebate schedule in Equity 7, Section 3 provide that member organizations may achieve better pricing if they achieve certain specified volumes of activity during a given month (as measured by Consolidated Volume (defined below) and Average Daily Volume (“ADV”)), the RASH issue may have impacted the ability of affected member organizations to reach the required volumes. By way of illustration, a member with shares of liquidity provided in all securities through one of its market participant identifiers (“MPIDs”) that represent more than 0.15% of the total consolidated volume reported to all consolidated transaction reporting plans by all exchanges and trade reporting facilities in equity securities of at least one round lot (“Consolidated Volume”) during a month receives a rebate of $0.0033 per share executed with respect to liquidity that it provides during the month through displayed orders. By contrast, member organizations providing lower volumes of liquidity receive lower rebates ranging from $0.0032-$0.0020 per share executed. If a member organization had provided liquidity that represented slightly in excess of 0.15% of Consolidated Volume on each day of December 2023 other than December 13, but was prevented from reaching comparable levels on that date due to the RASH issue, it is possible that the rebate it would ultimately earn for the entire month would be lower than would otherwise have been the case.</P>
                <P>Accordingly, in order to ensure that fees and rebates are not adversely impacted by the RASH issue, PHLX proposes to exclude December 13, 2023 from calculations of Consolidated Volume and ADV made under Equity 7, Section 3 if doing so would allow a member organization to achieve more favorable pricing than would be the case if the day were included. Thus, member organizations that are unaffected by the RASH issue would not have the day arbitrarily excluded from their calculations. PHLX will perform all calculations needed to implement the change.</P>
                <HD SOURCE="HD3">2. Statutory Basis</HD>
                <P>
                    The Exchange believes that its proposal is consistent with Section 6(b) of the Act,
                    <SU>3</SU>
                    <FTREF/>
                     in general, and furthers the objectives of Sections 6(b)(4) and 6(b)(5) of the Act,
                    <SU>4</SU>
                    <FTREF/>
                     in particular, in that it provides for the equitable allocation of reasonable dues, fees and other charges among member organizations and issuers and other persons using any facility, and is not designed to permit unfair discrimination between customers, issuers, brokers, or dealers.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         15 U.S.C. 78f(b).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         15 U.S.C. 78f(b)(4) and (5).
                    </P>
                </FTNT>
                <P>PHLX believes that the proposed change is reasonable because it will allow member organizations to receive December 2023 pricing that is based on either the exclusion, or the inclusion, of December 13, whichever is more favorable to the member organization. The proposed change is equitable and not unfairly discriminatory, because it will ensure that the fees and rebates applicable to member organizations that were subject to the RASH issue are not adversely affected by the issue.</P>
                <HD SOURCE="HD2">B. Self-Regulatory Organization's Statement on Burden on Competition</HD>
                <P>The Exchange does not believe that the proposed rule change will impose any burden on competition not necessary or appropriate in furtherance of the purposes of the Act. The change will help to ensure that member organizations that were affected by the RASH issue are not required to pay higher fees, or receive lower rebates, during December 2023 than would otherwise be the case. Accordingly, PHLX believes that the proposed changes will protect member organizations from incurring unanticipated charges.</P>
                <HD SOURCE="HD2">C. Self-Regulatory Organization's Statement on Comments on the Proposed Rule Change Received From Members, Participants, or Others</HD>
                <P>No written comments were either solicited or 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)(ii) of the Act.
                    <SU>5</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         15 U.S.C. 78s(b)(3)(A)(ii).
                    </P>
                </FTNT>
                <P>At any time within 60 days of the filing of the proposed rule change, the Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is: (i) necessary or appropriate in the public interest; (ii) for the protection of investors; or (iii) otherwise in furtherance of the purposes of the Act. If the Commission takes such action, the Commission shall institute proceedings to determine whether the proposed rule should be approved or disapproved.</P>
                <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">https://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-Phlx-2023-58 on the subject line.
                </P>
                <HD SOURCE="HD2">Paper Comments</HD>
                <P>
                    • Send paper comments in triplicate to Secretary, Securities and Exchange 
                    <PRTPAGE P="1138"/>
                    Commission, 100 F Street NE, Washington, DC 20549-1090.
                </P>
                <FP>
                    All submissions should refer to file number SR-Phlx-2023-58. 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">https://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 a.m. and 3 p.m. Copies of the filing also will be available for inspection and copying at the principal office of the Exchange. 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-Phlx-2023-58 and should be submitted on or before January 30, 2024.
                </FP>
                <SIG>
                    <P>
                        For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
                        <SU>6</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>6</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-00177 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">OFFICE OF THE UNITED STATES TRADE REPRESENTATIVE</AGENCY>
                <SUBJECT>Publication of 2024 Tariff Rate Quota Quantity Limitations Under the U.S.-Australia Free Trade Agreement</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the United States Trade Representative (USTR).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the U.S.-Australia Free Trade Agreement entered into by the United States and the Commonwealth of Australia, USTR is providing notice of tariff-rate quota quantity limitations of certain tariff subheadings for calendar year (CY) 2024.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The changes made by this notice are applicable as of January 1, 2024.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Sarah E. Fasano, Office of Agricultural Affairs, at (202) 395-6127 or 
                        <E T="03">Sarah.E.Fasano@ustr.eop.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Pursuant to section 201 of the United States-Australia Free Trade Agreement Implementation Act (Pub. L. 108-286; 118 Stat. 919) (19 U.S.C. 3805 note), Presidential Proclamation No. 7857 of December 20, 2004, and subchapter XXII of chapter 98 of the Harmonized Tariff Schedule of the United States (HTSUS), the Annex to this notice provides the quantitative limitations in 2024 of originating goods of Australia entering the United States under certain subheadings.</P>
                <HD SOURCE="HD1">Annex</HD>
                <P>Effective with respect to originating goods of Australia, entered under the terms of general note 28 to the HTSUS and under subchapter XXII of chapter 98, on or after January 1, 2024, and through the close of December 31, 2024:</P>
                <P>1. For purposes of U.S. note 8 to subchapter XXII of chapter 98 of the HTSUS, the aggregate quantity of originating goods of Australia entered under subheading 9822.04.01 shall not exceed 70,843 metric tons for CY2024.</P>
                <P>2. For purposes of U.S. note 9 to subchapter XXII of chapter 98 of the HTSUS, the aggregate quantity of originating goods of Australia entered under subheading 9822.04.05 shall not exceed 22,692,000 liters for CY2024.</P>
                <P>3. For purposes of U.S. note 10 to subchapter XXII of chapter 98 of the HTSUS, the aggregate quantity of originating goods of Australia entered under subheading 9822.04.10 shall not exceed 2,630 metric tons for CY2024.</P>
                <P>4. For purposes of U.S. note 11 to subchapter XXII of chapter 98 of the HTSUS, the aggregate quantity of originating goods of Australia entered under subheading 9822.04.15 shall not exceed 175 metric tons for CY2024.</P>
                <P>5. For purposes of U.S. note 12 to subchapter XXII of chapter 98 of the HTSUS, the aggregate quantity of originating goods of Australia entered under subheading 9822.04.20 shall not exceed 8,427 metric tons for CY2024.</P>
                <P>6. For purposes of U.S. note 13 to subchapter XXII of chapter 98 of the HTSUS, the aggregate quantity of originating goods of Australia entered under subheading 9822.04.25 shall not exceed 4,538 metric tons for CY2024.</P>
                <P>7. For purposes of U.S. note 14 to subchapter XXII of chapter 98 of the HTSUS, the aggregate quantity of originating goods of Australia entered under subheading 9822.04.30 shall not exceed 9,077 metric tons for CY2024.</P>
                <P>8. For purposes of U.S. note 15 to subchapter XXII of chapter 98 of the HTSUS, the aggregate quantity of originating goods of Australia entered under subheading 9822.04.35 shall not exceed 8,844 metric tons for CY2024.</P>
                <P>9. For purposes of U.S. note 16 to subchapter XXII of chapter 98 of the HTSUS, the aggregate quantity of originating goods of Australia entered under subheading 9822.04.40 shall not exceed 5,054 metric tons for CY2024.</P>
                <P>10. For purposes of U.S. note 17 to subchapter XXII of chapter 98 of the HTSUS, the aggregate quantity of originating goods of Australia entered under subheading 9822.04.45 shall not exceed 1,315 metric tons for CY2024.</P>
                <P>11. For purposes of U.S. note 18 to subchapter XXII of chapter 98 of the HTSUS, the aggregate quantity of originating goods of Australia entered under subheading 9822.04.50 shall not exceed 877 metric tons for CY2024.</P>
                <P>12. For purposes of U.S. note 19 to subchapter XXII of chapter 98 of the HTSUS, the aggregate quantity of originating goods of Australia entered under subheading 9822.04.65 shall not exceed 1,263 metric tons for CY2024.</P>
                <SIG>
                    <NAME>Douglas McKalip,</NAME>
                    <TITLE>Chief Agricultural Negotiator, Office of the United States Trade Representative.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00227 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3290-F4-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Aviation Administration</SUBAGY>
                <DEPDOC>[Docket No. FAA-2023-2111; Summary Notice No. 2024-01]</DEPDOC>
                <SUBJECT>Petition for Exemption; Summary of Petition Received; Software Development Alternatives, Inc.</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Aviation Administration (FAA), DOT.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of petition for exemption received.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        This notice contains a summary of a petition seeking relief from specified requirements of Federal Aviation Regulations. The purpose of this notice is to improve the public's awareness of, and participation in, the FAA's exemption process. Neither publication of this notice nor the inclusion or omission of information in the summary is intended to affect the 
                        <PRTPAGE P="1139"/>
                        legal status of the petition or its final disposition.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments on this petition must identify the petition docket number and must be received on or before January 29, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Send comments identified by docket number FAA-2023-2111 using any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal:</E>
                         Go to 
                        <E T="03">http://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">http://www.regulations.gov,</E>
                         as described in the system of records notice (DOT/ALL-14 FDMS), which can be reviewed at 
                        <E T="03">http://www.dot.gov/privacy.</E>
                    </P>
                    <P>
                        <E T="03">Docket:</E>
                         Background documents or comments received may be read at 
                        <E T="03">http://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>
                        Michael H. Harrison, AIR-646, Federal Aviation Administration, phone 206-231-3368, email 
                        <E T="03">Michael.Harrison@faa.gov.</E>
                    </P>
                    <P>This notice is published pursuant to 14 CFR 11.85.</P>
                    <SIG>
                        <DATED>Issued in Washington, DC, on January 2, 2024.</DATED>
                        <NAME>Daniel J. Commins,</NAME>
                        <TITLE>Manager, Integration and Performance.</TITLE>
                    </SIG>
                    <HD SOURCE="HD1">Petition for Exemption</HD>
                    <P>
                        <E T="03">Docket No.:</E>
                         FAA-2023-2111.
                    </P>
                    <P>
                        <E T="03">Petitioner:</E>
                         Software Development Alternatives, Inc.
                    </P>
                    <P>
                        <E T="03">Section(s) of 14 CFR Affected:</E>
                         § 21.603(a)(1).
                    </P>
                    <P>
                        <E T="03">Description of Relief Sought:</E>
                         Software Development Alternatives, Inc. (SDA) is seeking relief from 14 Code of Federal Regulations, § 21.603(a)(1), which requires in pertinent part, an applicant for a technical standard order (TSO) authorization must apply in the form and manner prescribed by the FAA and that the applicant must include a statement of conformance certifying that the applicant has met the requirements of this subpart and that the article concerned meets the applicable TSOs that were effective on the date of application for that article. Specifically, SDA is proposing the FAA grant an exemption to allow a TSOA submittal for the article to be evaluated against TSO-C160 and TSO-C113, which were effective when the article was approved for manufacture by the FAA on March 7th, 2012.
                    </P>
                </FURINF>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00191 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-13-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Highway Administration</SUBAGY>
                <SUBJECT>Request for Nominations for the Working Group on Covered Resources to the Federal Highway Administration</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Highway Administration (FHWA), U.S. Department of Transportation (DOT).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice to solicit members for the Working Group on Covered Resources.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The FHWA announces a request for nominations to the Working Group on Covered Resources (Working Group). The Working Group members will be appointed for a term of 2 years. The Working Group will conduct a study on access to covered resources for infrastructure projects. In carrying out the study, the Working Group shall analyze the use of covered resources in transportation projects funded with Federal dollars; how the proximity of covered resources to such projects affects the cost and environmental impact of those projects; whether and how State, Tribal, and local transportation and planning agencies consider covered resources when developing transportation projects; and any challenges for transportation project sponsors regarding access and proximity to covered resources. The Working Group shall submit to the Secretary of Transportation the findings of its study and any recommendations to preserve access to and reduce the costs and environmental impacts of covered resources in infrastructure projects.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The deadline for nominations for the Working Group membership is March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        All nomination materials should be emailed to 
                        <E T="03">Richard.Duval@dot.gov</E>
                         or mailed attention to Designated Federal Officer Mr. Richard Duval c/o Mrs. Gina Ahlstrom, Federal Highway Administration, Office of Infrastructure, Room E75-332, 1200 New Jersey Avenue SE, Washington, DC 20590. Any person needing accessibility accommodations should contact Richard Duval at (202) 515-1030.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Mr. Richard B. Duval, Office of Infrastructure, 1200 New Jersey Avenue SE, Washington, DC 20590, (202) 515-1030 or via email at 
                        <E T="03">Richard.Duval@dot.gov;</E>
                         or Ms. Alissa Dolan, Office of the Chief Counsel, 1200 New Jersey Avenue SE, Washington, DC 20590, (202) 631-3393 or via email at 
                        <E T="03">Alissa.Dolan@dot.gov</E>
                        .
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Section 11526 of the Bipartisan Infrastructure Law (BIL), enacted as the Infrastructure Investment and Jobs Act (Pub. L. 117-58), requires the establishment of a “Working Group on Covered Resources.” The term “covered resource” means a common variety material used in transportation infrastructure construction and maintenance, including stone, sand, and gravel. The Working Group will conduct a study on access to covered resources for infrastructure projects. Pursuant to BIL section 11526(d), in carrying out the study, the Working Group shall analyze the use of covered resources in transportation projects funded with Federal dollars; how the proximity of covered resources to such projects affects the cost and environmental impact of those projects; whether and how State, Tribal, and local transportation and planning agencies consider covered resources when developing transportation projects; and any challenges for transportation project sponsors regarding access and proximity to covered resources.</P>
                <P>
                    In conducting this study, BIL section 11526(e) requires the Working Group to consult, as appropriate, with chief executive officers of States; State, Tribal, and local transportation and planning agencies; other relevant State, Tribal, and local agencies, including State agencies associated with covered resources protection; members of the public with industry experience with respect to covered resources; other Federal entities that provide funding for transportation projects; and any other stakeholder the Working Group determines appropriate.
                    <PRTPAGE P="1140"/>
                </P>
                <P>In accordance with BIL section 11526(f)(1), not later than 2 years after the Working Group is established, it shall submit to the Secretary the findings of its study, including a summary of comments received during the consultation process required by section 11526(e), and any recommendations to preserve access to and reduce the costs and environmental impacts of covered resources in infrastructure projects. The Secretary will then submit to Congress a summary of the findings of the Working Group's report and any recommendations, as appropriate.</P>
                <P>In accordance with section 9 of the Federal Advisory Committee Act (FACA), and as directed by BIL section 11526(b), the Secretary has established the Working Group on Covered Resources. This document gives notice of the member nomination process to potential participants and affords them the opportunity to request representation on the Working Group. The procedure for requesting such representation is set out below. FHWA is aware that there are many more potential organizations and participants than there are membership slots on the Working Group. Organizations and participants should be prepared to support their request for representation on the Working Group.</P>
                <P>Members serve at the pleasure of the Secretary. Members will be appointed for a 2-year term with the potential for reappointment. The Secretary may extend appointments and may appoint replacements for members who have resigned outside of a stated term, as necessary. Members may continue to serve until their replacements have been appointed. The Working Group shall terminate 180 days after the date on which the Secretary receives the report required under BIL section 11526(f)(1).</P>
                <P>FHWA is hereby soliciting nominations for members of the Working Group. Members will have knowledge and expertise in the production and transportation of covered resources. As prescribed by BIL Section 11526(c)(2), the Secretary will appoint not less than one representative of each of the following:</P>
                <P>(1) State departments of transportation.</P>
                <P>(2) State agencies associated with covered resources protection.</P>
                <P>(3) State planning and geologic survey and mapping agencies.</P>
                <P>(4) Commercial motor vehicle operators, including small business operators and operators who transport covered resources.</P>
                <P>(5) Covered resources producers.</P>
                <P>(6) Construction contractors.</P>
                <P>(7) Labor organizations.</P>
                <P>(8) Metropolitan planning organizations and regional planning organizations.</P>
                <P>(9) Indian Tribes, including Tribal elected leadership or Tribal transportation officials.</P>
                <P>(10) Any other stakeholders that the Secretary determines appropriate.</P>
                <P>Process and Deadline for Submitting Nominations: Qualified individuals can self-nominate or be nominated by any individual or organization. To be considered for the Working Group, nominators should submit the following information:</P>
                <P>(1) Name, title, and relevant contact information (including phone, and email address) of the nominee.</P>
                <P>(2) A letter of support containing a brief description of why the nominee should be considered for membership.</P>
                <P>(3) A short biography of the nominee, including any relevant professional and academic credentials and any prior experience with covered resources.  </P>
                <P>(4) For nominees seeking to serve in their individual capacity (and not seeking appointment to represent the interests of a nongovernmental entity, a recognizable group of persons or nongovernmental entities such as an industry sector or labor union, or State or local governments), an affirmative statement that the nominee is not a federally registered lobbyist, and that the nominee understands that if appointed, the nominee will not be allowed to continue to serve as a Working Group member if the nominee becomes a federally registered lobbyist.</P>
                <P>(5) An affirmative statement from the nominee of their availability and willingness to serve on the Working Group. Initially, board members will be expected to participate in quarterly meetings and are expected to attend at least three-quarters of all meetings during their 2-year term. Additional meetings may be required.</P>
                <P>(6) An affirmative statement from the nominee of their willingness and ability to serve as the chairperson for the Working Group, which will require additional time commitment beyond simple membership. Chairperson duties are described in DOT Order 1120.3 D, “Committee Management Policy and Procedures.”</P>
                <P>Please do not send company, trade association, or organization brochures, or any other information. Materials submitted should total three pages or less, not including any letter(s) of support. Should more information be needed, DOT staff will contact the nominee, obtain information from the nominee's past affiliations, or obtain information from publicly available sources, such as the internet.</P>
                <P>It is important to recognize that interested parties who are not selected for membership on the Working Group can make valuable contributions to the work of the Working Group in several ways. Interested persons shall be permitted to attend, appear before, or file statements with any advisory committee, subject to such reasonable rules or regulations as the FHWA Administrator may prescribe.</P>
                <P>Any member of the public is welcome to attend Working Group meetings, and, as provided in FACA, speak to the Working Group. Time will be set aside during each meeting for this purpose, consistent with the Working Group's need for sufficient time to complete its deliberations.</P>
                <P>
                    All nomination materials should be emailed to 
                    <E T="03">Richard.Duval@dot.gov</E>
                     or mailed attention to Mr. Richard Duvalc/o Mrs. Gina Ahlstrom, Federal Highway Administration, Office of Infrastructure, Room E75-332, 1200 New Jersey Avenue SE, Washington, DC 20590. Any person needing accessibility accommodations should contact Richard Duval at (202) 515-1030. Nominations must be received by March 11, 2024. Nominees selected for appointment to the Working Group will be notified by return email and by a letter of appointment.
                </P>
                <P>A selection team comprising representatives from DOT offices and member(s) of the U.S. Department of the Interior U.S. Geological Survey will review the nomination packages. The selection team will make recommendations regarding membership to the Secretary through the FHWA Administrator based on evaluation criteria including: (1) professional or academic expertise, experience, and knowledge; (2) stakeholder representation; and (3) skills working on committees and advisory panels. The FHWA Administrator will submit a list of recommended candidates to the Secretary for review and selection of Working Group members.</P>
                <P>
                    Nominations are open to all individuals without regard to race, color, religion, sex, national origin, age, mental or physical handicap, marital status, or sexual orientation. To ensure that recommendations to the Secretary consider the needs of the diverse groups served by DOT, membership shall include, to the extent practicable, individuals with demonstrated ability to 
                    <PRTPAGE P="1141"/>
                    represent disadvantaged and under-represented groups.
                </P>
                <SIG>
                    <NAME>Shailen P. Bhatt,</NAME>
                    <TITLE>Administrator, Federal Highway Administration.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00251 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-22-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Highway Administration</SUBAGY>
                <DEPDOC>[Docket No. FHWA-2024-0001]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities: Notice of Request for Reinstatement of a Previously 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 reinstatement of a previously 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 new (periodic) 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 18, 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 February 8, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments identified by DOT Docket ID Number 0001 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>
                    </P>
                    <P>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>
                        Steven Jessberger, (202) 366-5052/
                        <E T="03">steven.jessberger@dot.gov;</E>
                         Patrick Zhang, (202) 366-1941/
                        <E T="03">patrick.zhang@dot.gov,</E>
                         Department of Transportation, Federal Highway Administration, Office Highway Policy Information, 1200 New Jersey Avenue SE, Washington, DC 20590. 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/>
                <P>
                    <E T="03">Title:</E>
                     Travel Monitoring Analysis System.
                </P>
                <P>
                    <E T="03">OMB Control #:</E>
                     2125-0587.
                </P>
                <P>
                    <E T="03">Background:</E>
                     The purpose of this document is to request OMB's three-year reinstatement for a previously approved information collection titled “Travel Monitoring Analysis System (TMAS),” covered by OMB Control No. 2125-0587. This information collection is due to expire on August 30, 2021. The Travel Monitoring Analysis System (TMAS) is the current system used to collect HVTIS information; therefore, the extension should now be titled Travel Monitoring Analysis System.
                </P>
                <HD SOURCE="HD1">Part A. Justification</HD>
                <HD SOURCE="HD2">1. Circumstances That Make the Collection of Information Necessary</HD>
                <P>23 U.S.C. 150 National Goals and Performance Management Measures requires that the U.S. DOT to establish a performance management system for its Federal-aid highway program. The Federal Highway Administration (FHWA), U.S. Department of Transportation (DOT) promulgated the performance management via 23 CFR part 490: National Performance Management Measures. Traffic data, including volume (# of vehicles and travelers), class (types of vehicles), weight (weight of vehicles), and travel time (speed), are parameters the performance management program relies upon.</P>
                <P>The FHWA is planning to continue to collect these traffic data through the TMAS system. To carry out the data collection, the FHWA will request that State Departments of Transportations (SDOTs) provide traffic volume, vehicle classification, vehicle speed, vehicle weight data, and nonmotorized data, which they collect as part of their traffic monitoring programs.</P>
                <P>In addition, 23 CFR 1.5 and 49 CFR 1.48 provide the Federal Highway Administrator with authority to request such information deemed necessary to administer the Federal-aid highway program. Traffic data are used for assessing highway system performance under FHWA's strategic planning and performance reporting process in accordance with the requirement of the Government Performance and Results Act (GPRA, Sections 3 and 4).</P>
                <P>Finally, both the 23 U.S.C. 503 and the 23 CFR 420.105(b) require States to provide data that support FHWA's responsibilities carrying out the Federal-aid highway program to Congress and the public.</P>
                <P>The data to be collected will continue to be used by the FHWA and other DOT agencies to (a) manage its Federal-aid highway program through the performance management mechanism, (b) evaluate changes in vehicular and nonmotorized travel to assess impacts on highway safety, (c) analyze the role of travel in economic development and productivity, (d) assess impacts from truck travel on infrastructure demands, and (e) maintain and improve our Nation's mobility while protecting the human and natural environment.</P>
                <HD SOURCE="HD2">2. How, by Whom, and for What Purpose Is the Information Used</HD>
                <P>The data submitted through TMAS will provide the amount and nature of vehicular travel at the national, regional, and state levels. The data also provide information on how vehicular travel pattern varies by hour of the day, day of the week, the month of the year, and year to year. Data submitted under the TMAS program are essential to the FHWA and the U.S. DOT in determining:</P>
                <FP SOURCE="FP-1">• The effectiveness of current highway programs in supporting travel demands, safety improvement, and travel reliability</FP>
                <FP SOURCE="FP-1">• The potential of possible modifications to the Federal-aid highway program, and</FP>
                <FP SOURCE="FP-1">• The need for new programs</FP>
                <FP SOURCE="FP-1">• The adequacy of the U.S. DOT Strategic Goals in areas of:</FP>
                <P>
                    i. 
                    <E T="03">Safety exposures:</E>
                     providing accurate and detailed exposure information related to travel and especially the roles of different vehicles in the same traffic stream
                </P>
                <P>
                    ii. 
                    <E T="03">Mobility:</E>
                     providing data on the relative usage of system capacity by various vehicles by time of day and the associated share of congestion that may be implicit in such travel
                </P>
                <P>
                    iii. 
                    <E T="03">Productivity:</E>
                     providing data necessary to estimate the tonnage of goods and number of people being moved by time of day, and season of the year over the various highway systems and
                </P>
                <P>
                    iv. 
                    <E T="03">Human and Natural Environment:</E>
                     providing data needed for the highway noise and air quality effect assessments.  
                </P>
                <P>
                    State highway agencies use the traffic data for project and program level applications such as geometric design, pavement design, safety analysis, overweight and oversize vehicle permitting, designating truck routes, estimating trends in freight movement, highway noise abatement needs assessment.
                    <PRTPAGE P="1142"/>
                </P>
                <P>In addition to the usage by the Federal and State governmental agencies, institutions of higher learning, industry, consultants, professional organizations, and the public are using the data for research and education, business development, and general information.</P>
                <HD SOURCE="HD2">3. Extent of Automated Information Collection</HD>
                <P>All data for the TMAS will be submitted electronically to the FHWA by all State highway and some local agencies, including the District of Columbia and Puerto Rico Departments of Transportation. Reliance on electronic reporting is responsive to limited staff resources at both the local, State and Federal levels. With the unlimited data upload file size, online electronic submission reduces burden to all respondents.</P>
                <P>The collected data will be further inserted into a Geographical Information System by the FHWA in order to support the analysis of point-specific vehicle travel data on a network basis. This is expected to allow:</P>
                <P>• Correlation of pavement loadings generated by vehicles to data in other FHWA systems that report pavement condition;</P>
                <P>• Major truck and interregional passenger corridors will be more readily identifiable among the links comprising the Nation's highway network, and;</P>
                <P>• Weather, natural disaster and other geographically related phenomena can be more readily related to associated changes in travel patterns</P>
                <P>All data summarization, processing, and editing are fully automated. The TMAS is supported by various software browsers for use by the local, States and FHWA staff in order to report, edit and summarize the collected data.</P>
                <P>
                    <E T="03">Respondents:</E>
                     State Departments of Transportation Agencies and Metropolitan Planning Organizations and Local Agencies responsible for submitting traffic data (both motorized and micromobility) to FHWA.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     All data for the TMAS will be submitted electronically monthly to the FHWA by all State highway and some local agencies, including the District of Columbia and Puerto Rico Departments of Transportation. Reliance on electronic reporting is responsive to limited staff resources at both the local, State and Federal levels. With the unlimited data upload file size, online electronic submission reduces burden to all respondents.
                </P>
                <P>The collected data will be further inserted into a Geographical Information System by the FHWA in order to support the analysis of point-specific vehicle travel data on a network basis. This is expected to allow:</P>
                <P>• Correlation of pavement loadings generated by vehicles to data in other FHWA systems that report pavement condition;</P>
                <P>• Major truck and interregional passenger corridors will be more readily identifiable among the links comprising the Nation's highway network, and;</P>
                <P>• Weather, natural disaster and other geographically related phenomena can be more readily related to associated changes in travel patterns</P>
                <P>All data summarization, processing, and editing are fully automated. The TMAS is supported by various software browsers for use by the local, States and FHWA staff in order to report, edit and summarize the collected data.</P>
                <P>
                    <E T="03">Estimated Average Burden per Response:</E>
                     FHWA estimates that the average State DOT operates 60 continuous vehicle classification installations, and 15 weigh-in-motion sites. State highway agencies have established their Traffic Monitoring System (TMS) under the Intermodal Surface Transportation Efficiency Act, Transportation Equity Act for the 21st Century, and the Safe, Accountable, Flexible, Efficient Transportation Equity Act: A Legacy for Users. The data collection burden relevant for this notice is the additional burden for each State to provide a copy of its traffic data per data formats specified in the FHWA 
                    <E T="03">Traffic Monitoring Guide.</E>
                     Automation and online tools continue to be developed and improved in support of the TMAS and the capability now exists for online submission and validation of volume, speed, classification and weight data. The combined burden for the monthly report is estimated to be 50 hours per respondent. The estimated total burden for all States, the District of Columbia, and Puerto Rico are 2,600 hours.
                </P>
                <P>Salary costs associated with burden hours are estimated at an average of $35.50 per hour for the technical specialists dealing with the TMAS data types. The hourly rate is taken from Table 452 of the 2007 Statistical Abstract of the United States Census Bureau. These costs are calculated as follows: $35.50 × 2,600 hours = $92,300.</P>
                <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,12,12,12">
                    <TTITLE>Estimated Total Annual Burden Hours</TTITLE>
                    <BOXHD>
                        <CHED H="1">Data type</CHED>
                        <CHED H="1">
                            Reportings
                            <LI>per year</LI>
                            <LI>per site</LI>
                        </CHED>
                        <CHED H="1">
                            Average
                            <LI>hours per</LI>
                            <LI>response</LI>
                        </CHED>
                        <CHED H="1">
                            Hours per
                            <LI>year per</LI>
                            <LI>state</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Site Description</ENT>
                        <ENT>1</ENT>
                        <ENT>2</ENT>
                        <ENT>2</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Vehicle Classification</ENT>
                        <ENT>12</ENT>
                        <ENT>1</ENT>
                        <ENT>12</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Vehicle Speed</ENT>
                        <ENT>12</ENT>
                        <ENT>1</ENT>
                        <ENT>12</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Vehicle Weight</ENT>
                        <ENT>12</ENT>
                        <ENT>1</ENT>
                        <ENT>12</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Total Volume</ENT>
                        <ENT>12</ENT>
                        <ENT>0.5</ENT>
                        <ENT>6</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="01">Total Nonmotorized Volume</ENT>
                        <ENT>12</ENT>
                        <ENT>0.5</ENT>
                        <ENT>6</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Total Hours per State per Year</ENT>
                        <ENT/>
                        <ENT/>
                        <ENT>50</ENT>
                    </ROW>
                </GPOTABLE>
                <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: January 4, 2024.</DATED>
                    <NAME>Jazmyne Lewis,</NAME>
                    <TITLE>Information Collection Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00213 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-22-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="1143"/>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Motor Carrier Safety Administration</SUBAGY>
                <DEPDOC>[Docket No. FMCSA-2017-0058; FMCSA-2018-0136; FMCSA-2018-0138; FMCSA-2018-0139; FMCSA-2019-0109; FMCSA-2019-0110]</DEPDOC>
                <SUBJECT>Qualification of Drivers; Exemption Applications; Hearing</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 of final disposition.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>FMCSA announces its decision to renew exemptions for 16 individuals from the hearing requirement in the Federal Motor Carrier Safety Regulations (FMCSRs) for interstate commercial motor vehicle (CMV) drivers. The exemptions enable these hard of hearing and deaf individuals to continue to operate CMVs in interstate commerce.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The exemptions were applicable on December 26, 2023. The exemptions expire on December 26, 2025.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Ms. Christine A. Hydock, Chief, Medical Programs Division, FMCSA, DOT, 1200 New Jersey Avenue SE, Room W64-224, Washington, DC 20590-0001, (202) 366-4001, 
                        <E T="03">fmcsamedical@dot.gov.</E>
                         Office hours are 8:30 a.m. to 5 p.m. ET Monday through Friday, except Federal holidays. If you have questions regarding viewing or submitting material to the docket, contact Dockets Operations, (202) 366-9826.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Public Participation</HD>
                <HD SOURCE="HD2">A. Viewing Comments</HD>
                <P>
                    To view comments go to 
                    <E T="03">www.regulations.gov.</E>
                     Insert the docket number (FMCSA-2017-0058, FMCSA-2018-0136, FMCSA-2018-0138, FMCSA-2018-0139, FMCSA-2019-0109, or FMCSA-2019-0110) in the keyword box and click “Search.” Next, sort the results by “Posted (Newer-Older),” choose the first notice listed, and 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. ET 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">B. Privacy Act</HD>
                <P>
                    In accordance with 49 U.S.C. 31315(b)(6), DOT solicits comments from the public on the exemption requests. DOT posts these comments, without edit, including any personal information the commenter provides, to 
                    <E T="03">www.regulations.gov.</E>
                     As described in the system of records notice DOT/ALL 14 (Federal Docket Management System), which can be reviewed at 
                    <E T="03">https://www.transportation.gov/individuals/privacy/privacy-act-system-records-notices,</E>
                     the comments are searchable by the name of the submitter.
                </P>
                <HD SOURCE="HD1">II. Background</HD>
                <P>On November 27, 2023, FMCSA published a notice announcing its decision to renew exemptions for 16 individuals from the hearing standard in 49 CFR 391.41(b)(11) to operate a CMV in interstate commerce and requested comments from the public (88 FR 82942). The public comment period ended on December 27, 2023, and no comments were received.</P>
                <P>FMCSA has evaluated the eligibility of these applicants and determined that renewing these exemptions would likely achieve a level of safety that is equivalent to, or greater than, the level that would be achieved by complying with § 391.41(b)(11).</P>
                <P>The physical qualification standard for drivers regarding hearing found in § 391.41(b)(11) states that a person is physically qualified to drive a CMV if that person first perceives a forced whispered voice in the better ear at not less than 5 feet with or without the use of a hearing aid or, if tested by use of an audiometric device, does not have an average hearing loss in the better ear greater than 40 decibels at 500 Hz, 1,000 Hz, and 2,000 Hz with or without a hearing aid when the audiometric device is calibrated to American National Standard (formerly ASA Standard) Z24.5—1951.</P>
                <P>This standard was adopted in 1970 and was revised in 1971 to allow drivers to be qualified under this standard while wearing a hearing aid (35 FR 6458, 6463 (Apr. 22, 1970) and 36 FR 12857 (July 8, 1971), respectively).</P>
                <HD SOURCE="HD1">III. Discussion of Comments</HD>
                <P>FMCSA received no comments in this proceeding.</P>
                <HD SOURCE="HD1">IV. Conclusion</HD>
                <P>Based upon its evaluation of the 16 renewal exemption applications and comments received, FMCSA announces its decision to exempt the following drivers from the hearing requirement in § 391.41 (b)(11).</P>
                <P>As of December 26, 2023, and in accordance with 49 U.S.C. 31136(e) and 31315(b), the following 16 individuals have satisfied the renewal conditions for obtaining an exemption from the hearing requirement in the FMCSRs for interstate CMV drivers (88 FR 82943; 88 FR 82944):</P>
                <FP SOURCE="FP-1">Denis Ayers (MD)</FP>
                <FP SOURCE="FP-1">Joseph Bence (OH)</FP>
                <FP SOURCE="FP-1">Daryl Broker (MN)</FP>
                <FP SOURCE="FP-1">Justin Brooks (WA)</FP>
                <FP SOURCE="FP-1">Christa Butner (NC)</FP>
                <FP SOURCE="FP-1">William Darnell (AZ)</FP>
                <FP SOURCE="FP-1">Travis Davisson (IA)</FP>
                <FP SOURCE="FP-1">Steven Gandee (PA)</FP>
                <FP SOURCE="FP-1">Derek Hawkins (NH)</FP>
                <FP SOURCE="FP-1">James Johnson (MN)</FP>
                <FP SOURCE="FP-1">Keith Kenyon (WI)</FP>
                <FP SOURCE="FP-1">John Martikainen (CT)</FP>
                <FP SOURCE="FP-1">Willis Ryan (GA)</FP>
                <FP SOURCE="FP-1">John Silvers (NY)</FP>
                <FP SOURCE="FP-1">Jeremy Williams (CA)</FP>
                <FP SOURCE="FP-1">Joseph Williams (MD)</FP>
                <P>The drivers were included in docket numbers FMCSA-2017-0058, FMCSA-2018-0136, FMCSA-2018-0138, FMCSA-2018-0139, FMCSA-2019-0109, or FMCSA-2019-0110. Their exemptions were applicable as of December 26, 2023 and will expire on December 26, 2025.</P>
                <P>In accordance with 49 U.S.C. 31315(b), each exemption will be valid for 2 years from the effective date unless revoked earlier by FMCSA. The exemption will be revoked if the following occurs: (1) the person fails to comply with the terms and conditions of the exemption; (2) the exemption has resulted in a lower level of safety than was maintained prior to being granted; or (3) continuation of the exemption would not be consistent with the goals and objectives of 49 U.S.C. 31136, 49 U.S.C. chapter 313, or the FMCSRs.</P>
                <SIG>
                    <NAME>Larry W. Minor,</NAME>
                    <TITLE>Associate Administrator for Policy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00258 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-EX-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <DEPDOC>[DOT-OST-2023-0165]</DEPDOC>
                <SUBJECT>Solicitation for Annual Combating Human Trafficking in Transportation Impact Award</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Secretary of Transportation, U.S. Department of Transportation.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The annual Combating Human Trafficking in Transportation Impact Award (the award) seeks to raise awareness among transportation 
                        <PRTPAGE P="1144"/>
                        stakeholders about human trafficking and increase training and prevention to combat the crime. The award is a component of the Department of Transportation (DOT) Transportation Leaders Against Human Trafficking initiative. Additional information regarding the Department's counter-trafficking activities can be found at 
                        <E T="03">www.transportation.gov/stophumantrafficking.</E>
                         The award serves as a platform for transportation stakeholders to creatively develop impactful and innovative counter-trafficking tools, initiatives, campaigns, and technologies that can help stop these heinous crimes. The award is open to individuals and entities, including non-governmental organizations, transportation industry associations, research institutions, and state and local government organizations. Entrants compete for a cash award of up to $50,000 to be awarded to the individual(s) or entity selected for creating the most impactful counter-trafficking initiative or technology. DOT intends to incentivize individuals and entities to think creatively in developing innovative solutions to combat human trafficking in the transportation industry, and to share those innovations with the broader community.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Submissions will be accepted from January 9, 2024 through midnight EST on March 11, 2024.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For more information and to register your intent to compete individually or as part of a team, visit 
                        <E T="03">www.transportation.gov/stophumantrafficking,</E>
                         email 
                        <E T="03">trafficking@dot.gov,</E>
                         or contact the Office of International Transportation and Trade at (202) 366-4398.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Award Approving Official:</E>
                     The Secretary of Transportation (Secretary).
                </P>
                <P>
                    <E T="03">Subject of Award Competition:</E>
                     The Combating Human Trafficking in Transportation Impact Award recognizes impactful, innovative, and shareable approaches to combating human trafficking in the transportation industry.
                </P>
                <HD SOURCE="HD1">Problem</HD>
                <P>As many as 27.6 million men, women, and children are held against their will and trafficked into forced labor and commercial sex. Transportation figures prominently in human trafficking enterprises when traffickers move victims, which uniquely positions the industry to combat the crime.</P>
                <HD SOURCE="HD1">Challenge</HD>
                <P>The Combating Human Trafficking in Transportation Impact Award is looking for the best innovators to develop original, impactful, unique, and shareable human trafficking tools, initiatives, campaigns, and technologies that can help stop these heinous crimes in the transportation industry.</P>
                <HD SOURCE="HD1">Eligibility</HD>
                <P>To be eligible to participate in the Combating Human Trafficking in Transportation Impact Award competition, private entities must be incorporated in and maintain a primary place of business in the United States, and individuals must be citizens or permanent residents of the United States. There is no charge to enter the competition.</P>
                <HD SOURCE="HD1">Rules, Terms, and Conditions</HD>
                <P>The following additional rules apply:</P>
                <P>1. Entrants shall submit a project to the competition under the rules promulgated by the Department in this Notice;</P>
                <P>2. Entrants must indemnify, defend, and hold harmless the Federal Government from and against all third-party claims, actions, or proceedings of any kind and from any and all damages, liabilities, costs, and expenses relating to or arising from participant's submission or any breach or alleged breach of any of the representations, warranties, and covenants of participant hereunder. Entrants are financially responsible for claims made by a third party;</P>
                <P>3. Entrants may not be a Federal entity or Federal employee acting within the scope of employment;</P>
                <P>4. Entrants may not be an employee of the U.S. Department of Transportation;</P>
                <P>5. Entrants shall not be deemed ineligible because an individual used Federal facilities or consulted with Federal employees during a competition if the facilities and employees are made available to all individuals participating in the competition on an equitable basis;</P>
                <P>6. The entries cannot have been submitted in the same or substantially similar form in any other previous Federally sponsored promotion or Federally sponsored competition;</P>
                <P>7. Entrants previously awarded first place are not eligible to reenter for the same or substantially similar project;</P>
                <P>8. Entries which, in the Department's sole discretion, are determined to be substantially similar to another entity's entry submitted to this competition may be disqualified;</P>
                <P>9. The competition is subject to all applicable Federal laws and regulations. Participation constitutes the entrants' full and unconditional agreement to these rules and to the Secretary's decisions, which are final and binding in all matters related to this competition;</P>
                <P>10. Entries must be original, be the work of the entrant and/or nominee and must not violate the rights of other parties. All entries remain the property of the entrant. Each entrant represents and warrants that:</P>
                <P>• Entrant is the sole author and owner of the submission;</P>
                <P>• The entry is not the subject of any actual or threatened litigation or claim;</P>
                <P>• The entry does not and will not violate or infringe upon the intellectual property rights, privacy rights, publicity rights, or other legal rights of any third party; and</P>
                <P>• The entry does not and will not contain any harmful computer code (sometimes referred to as “malware,” “viruses,” or, “worms”).</P>
                <P>11. By submitting an entry in this competition, entrants agree to assume any and all risks and waive any claims against the Federal Government and its related entities (except in the case of willful misconduct) for any injury, death, damage, or loss of property, revenue or profits, whether direct, indirect, or consequential, arising from their participation in this competition, whether the injury, death, damage, or loss arises through negligence of otherwise. Provided, however, that by registering or submitting an entry, entrants and/or nominees do not waive claims against the Department arising out of the unauthorized use or disclosure by the agency of the intellectual property, trade secrets, or confidential information of the entrant;</P>
                <P>12. The Secretary or the Secretary's designees have the right to request additional supporting documentation regarding the application from the entrants and/or nominees;</P>
                <P>13. Each entrant grants to the Department, as well as other Federal agencies with which it partners, the right to use names, likeness, application materials, photographs, voices, opinions, and hometown and state for the Department's promotional purposes in any media, in perpetuity, worldwide, without further payment or consideration;</P>
                <P>
                    14. If selected, the entrant and/or nominee must provide written consent granting the Department and any parties acting on their behalf, a royalty-free, non-exclusive, irrevocable, worldwide license to display publicly and use for promotional purposes the entry (“demonstration license”). This demonstration license includes posting 
                    <PRTPAGE P="1145"/>
                    or linking to the entry on Department websites, including the Competition website, and partner websites, and inclusion of the entry in any other media, worldwide;
                </P>
                <P>15. Applicants that are Federal grant recipients may not use Federal funds to develop submissions;</P>
                <P>16. Federal contractors may not use Federal funds from a contract to develop applications or to fund efforts in support of a submission; and</P>
                <P>17. The submission period begins on January 9, 2024. Submissions must be sent by 11:59 p.m. Eastern Standard Time on March 11, 2024. The timeliness of submissions will be determined by the postmark (if sent in hard copy) or time stamp of the recipient (if emailed). Competition administrators assume no responsibility for lost or untimely submissions for any reason.</P>
                <HD SOURCE="HD1">Submission Requirements</HD>
                <P>
                    Applicants must submit entries using the submission chart in Appendix A via email or by mail. Electronic packages may be transmitted by email to: 
                    <E T="03">trafficking@dot.gov.</E>
                     Hard copies should be forwarded with a cover letter to the attention of: Combating Human Trafficking in Transportation Impact Award (Room W88-121), 1200 New Jersey Avenue SE, Washington, DC 20590.
                </P>
                <P>
                    <E T="03">Expression of Interest: While not required, entrants are strongly encouraged to send brief expressions of interest to DOT prior to submitting entries. The expressions of interest should be sent by February 8, 2024 to trafficking@dot.gov, and include the following elements: (1) Name and title of entrant(s); (2) Telephone and email address; and (3) A synopsis of the concept, limited to no more than two pages.</E>
                </P>
                <P>
                    Please ensure your submission package includes 
                    <E T="03">EACH</E>
                     of the following twelve elements (see required submission chart in Appendix A):
                </P>
                <HD SOURCE="HD2">1. Mode(s)</HD>
                <P>Specify which transportation mode(s) the proposal will focus on.</P>
                <HD SOURCE="HD2">2. Title</HD>
                <P>The proposal title.</P>
                <HD SOURCE="HD2">3. Entity</HD>
                <P>The name of the organization(s) being nominated, or the name(s) and title(s) of the individual(s) being nominated.</P>
                <HD SOURCE="HD2">4. Submitted By</HD>
                <P>Include name, title, phone, email, website URL, and mailing address.</P>
                <P>If the point of contact for the proposal is different, also specify their name, title, phone, and email.  </P>
                <HD SOURCE="HD2">5. Background</HD>
                <P>Brief background regarding the submitting individual(s) or organization(s) that includes relevant counter-trafficking expertise.</P>
                <HD SOURCE="HD2">6. Partners</HD>
                <P>If applicable, list the partners who will be engaged in proposal development and/or implementation, including a brief background for each.</P>
                <HD SOURCE="HD2">7. Letters of Support</HD>
                <P>You may submit supporting letters, which may be from subject matter experts or industry, and may address the technical merit of the concept, originality, impact, practicality, measurability and/or applicability. Proposals with letters of support should include an itemized list with the name, title, and organization for each letter.</P>
                <HD SOURCE="HD2">8. Proposal Description (1 sentence)</HD>
                <P>
                    A high-level description of the proposal including 
                    <E T="03">all</E>
                     deliverable(s).
                </P>
                <HD SOURCE="HD2">9. Proposal Summary (1 paragraph)</HD>
                <P>
                    A detailed synopsis of the proposal, including how efficacy will be 
                    <E T="03">measured</E>
                     and its anticipated 
                    <E T="03">impact.</E>
                </P>
                <HD SOURCE="HD2">10. Proposal Overview and Impact/Measurability (1-2 pages)</HD>
                <P>
                    A proposal description that presents a logical approach and workable solution to addressing the issue of human trafficking in the transportation industry. Include responses to the following questions: Is the concept unique? Are anticipated beneficiaries clearly identified? Were human trafficking survivors consulted in the proposal development and/or how will survivor input be included in implementation? Are anticipated resources and costs outlined in detail? Can the proposal be implemented in a way requiring a finite amount of resources (
                    <E T="03">e.g.,</E>
                     fixed costs, low or no marginal costs, and a clear path to implementation and scale beyond an initial investment)? For impact and measurability, include a description of how the proposal will be evaluated, and its potential impact on human trafficking in the transportation industry. 
                    <E T="03">Include responses to the following questions:</E>
                     How will the proposal's impact be measured? How will the proposal contribute to counter-trafficking efforts in the transportation sector? If not a national proposal, can the proposal be scaled nationally?
                </P>
                <HD SOURCE="HD2">11. Supporting Documents (no page limit)</HD>
                <P>The paper(s) and/or technologies, programs, video/audio files, and other related materials, describing the proposal and addressing the selection criteria. As applicable, this can include a description of success of a previous or similar proposal and/or documentation of impact. DOT may request additional information, including supporting documentation, more detailed contact information, releases of liability, and statements of authenticity to guarantee the originality of the work. Failure to respond in a timely manner may result in disqualification.</P>
                <HD SOURCE="HD2">12. Eligibility Statement</HD>
                <P>A statement of eligibility by private entities indicating that they are incorporated in and maintain a primary place of business in the United States, or a statement of eligibility by individuals indicating that they citizens or permanent residents of the United States.</P>
                <HD SOURCE="HD1">Initial Screening</HD>
                <P>The Office of International Transportation and Trade (OITT) will initially review applications to determine that all required submission elements are included, and to determine compliance with eligibility requirements.</P>
                <HD SOURCE="HD1">Evaluation</HD>
                <P>After the Initial Screening, OITT, with input from the relevant Operating Administrations, will judge entries based on the factors described below: technical merit, originality, impact, practicality, measurability, and applicability. The Secretary will make the final selection. The Department reserves the right to not award the prize if the selecting officials believe that no submission demonstrates sufficient potential for sufficient transformative impact. The following factors are equally important and will be given consideration.</P>
                <HD SOURCE="HD2">Technical Merit</HD>
                <P>• Does the proposal present a clear understanding of the issue of human trafficking in the transportation industry and utilizes a trauma-informed, victim-centered approach?</P>
                <P>• Does the proposal present a logical and workable solution and approach to addressing human trafficking in the transportation industry?</P>
                <P>• Were survivors of human trafficking consulted in the development of the proposal concept and is survivor input outlined in the description of proposal implementation?</P>
                <HD SOURCE="HD2">Originality</HD>
                <P>
                    • Is the concept new or a variation of an existing idea?
                    <PRTPAGE P="1146"/>
                </P>
                <P>• Does the concept possess and clearly describe its unique merits?</P>
                <HD SOURCE="HD2">Impact/Measurability</HD>
                <P>• Can the proposal make a significant impact and/or contribution to the fight against human trafficking in the transportation industry?</P>
                <P>• Does the proposal clearly describe the breadth of impact?</P>
                <P>• Does the submission clearly outline how the proposal will be measured?</P>
                <P>• Will the proposal result in measurable improvements?</P>
                <HD SOURCE="HD2">Practicality</HD>
                <P>• Does the proposal clearly identify anticipated beneficiaries of the proposal?</P>
                <P>• Does the proposal clearly outline anticipated resources and all costs to be incurred by executing the concept?</P>
                <P>• Can the proposal be implemented in a way that requires a finite amount of resources (specifically, the submission has fixed costs, low or no marginal costs, and a clear path to implementation and scale beyond an initial investment)?</P>
                <HD SOURCE="HD2">Applicability</HD>
                <P>• Is the proposal national and/or can it be scaled nationally?</P>
                <HD SOURCE="HD1">Award</HD>
                <P>Up to three winning entries are expected to be announced. The first-place winner will receive up to a $50,000 cash prize. A plaque with the first-place winner(s) name and the date of the award will be on display at the U.S. Department of Transportation, and a display copy of the plaque(s) will be sent to the first-place award winner's headquarters. Two additional plaques will be awarded to recognize the two runners up. At the Department's discretion, DOT may pay for invitational travel expenses to Washington, DC, for up to two individuals or representatives of the first-place winning organization and runners up organizations, should selectees be invited to present their proposal(s) for DOT officials.</P>
                <EXTRACT>
                    <FP>(Authority: 15 U.S.C. 3719 (America COMPETES Act))</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Issued in Washington, DC, on January 3, 2024.</DATED>
                    <NAME>Carol A. Petsonk,</NAME>
                    <TITLE>Assistant Secretary for Aviation and International Affairs.</TITLE>
                </SIG>
                <HD SOURCE="HD1">APPENDIX A</HD>
                <EXTRACT>
                    <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s50,r150">
                        <TTITLE>U.S. Department of Transportation Combating Human Trafficking in Transportation Impact Award 2024 Proposal Submission Form</TTITLE>
                        <BOXHD>
                            <CHED H="1">Section</CHED>
                            <CHED H="1">Instructions</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">1. Mode(s)</ENT>
                            <ENT>Specify which transportation mode(s) the proposal will focus on.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2. Title</ENT>
                            <ENT>The proposal title.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">3. Entity</ENT>
                            <ENT>The name of the organization(s) being nominated, or the name(s) and title(s) of the individual(s) being nominated.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">4. Submitted By</ENT>
                            <ENT>• Name/Title.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>• Phone.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>• Email.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>• Website URL.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>• Mailing address.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>
                                <E T="03">If the point of contact for the proposal is different, also specify their name, title, phone, and email.</E>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5. Background</ENT>
                            <ENT>Brief background regarding the submitting individual(s) or organization(s) that includes relevant counter-trafficking expertise.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">6. Partners</ENT>
                            <ENT>If applicable, list the partners who will be engaged in proposal development and/or implementation, including a brief background for each.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">7. Letters of Support</ENT>
                            <ENT>You may submit supporting letters, which may be from subject matter experts or industry, and may address the technical merit of the concept, originality, impact, practicality, measurability and/or applicability. Proposals with letters of support should include an itemized list with the name, title, and organization for each letter.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                8. Proposal Description 
                                <E T="03">(1 sentence)</E>
                            </ENT>
                            <ENT>
                                A high-level description of the proposal including 
                                <E T="03">all</E>
                                 deliverable(s).
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                9. Proposal Summary 
                                <E T="03">(1 paragraph)</E>
                            </ENT>
                            <ENT>
                                A detailed synopsis of the proposed proposal, including how efficacy will be 
                                <E T="03">measured</E>
                                 and its anticipated 
                                <E T="03">impact.</E>
                                 Ensure the types of efforts that will be engaged in are highlighted (
                                <E T="03">for example, training, partnerships, public awareness, policies, reporting protocols, data collection, information-sharing, victim/survivor support, etc.</E>
                                ).
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                10. Proposal Overview and Impact/Measurability 
                                <E T="03">(1-2 pages)</E>
                            </ENT>
                            <ENT>A description of the proposal that presents a logical approach and workable solution to addressing the issue of human trafficking in the transportation industry. Ensure that each of the following 6 questions are addressed:</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>(a) Is the concept unique?</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>(b) Are the anticipated beneficiaries clearly identified?</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>(c) Were human trafficking survivors consulted in the development of the proposal and/or how will survivor input be included in proposal implementation?</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>(d) Are the anticipated resources and costs outlined in detail?</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>
                                (e) Can the proposal be implemented in a way requiring a finite amount of resources (
                                <E T="03">e.g.,</E>
                                 the submission has fixed costs, low or no marginal costs, and a clear path to implementation and scale beyond an initial investment)?
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>(f) For impact and measurability, include a description of how the proposal will be evaluated, and its potential impact on human trafficking in the transportation industry. Ensure the following questions are addressed: </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>i. How will the proposal's impact be measured?</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>ii. How will the proposal contribute to counter-trafficking efforts in the transportation sector?</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>iii. If not a national proposal, can it be scaled nationally?</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="1147"/>
                            <ENT I="01">
                                11. Supporting Documents 
                                <E T="03">(no page limit)</E>
                            </ENT>
                            <ENT>The paper(s) and/or technologies, programs, video/audio files, and other related materials, describing the proposal and addressing the selection criteria. As applicable, this can include a description of success of a previous or similar proposal and/or documentation of impact. DOT may request additional information, including supporting documentation, more detailed contact information, releases of liability, and statements of authenticity to guarantee the originality of the work. Failure to respond in a timely manner may result in disqualification.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">12. Eligibility Statement</ENT>
                            <ENT>A statement of eligibility by private entities indicating that they are incorporated in and maintain a primary place of business in the United States, or a statement of eligibility by individuals indicating that they citizens or permanent residents of the United States.</ENT>
                        </ROW>
                    </GPOTABLE>
                </EXTRACT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00215 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-9X-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF THE TREASURY</AGENCY>
                <SUBJECT>Departmental Offices; Debt Management Advisory Committee Meeting</SUBJECT>
                <P>Notice is hereby given, pursuant to 5 U.S.C. App. 2, section 10(a)(2), that a meeting will be held at the United States Treasury Department, 15th Street and Pennsylvania Avenue NW, Washington, DC on January 30, 2024, at 9:00 a.m., of the following debt management advisory committee: Treasury Borrowing Advisory Committee.</P>
                <P>At this meeting, the Treasury is seeking advice from the Committee on topics related to the economy, financial markets, Treasury financing, and debt management. Following the working session, the Committee will present a written report of its recommendations. The meeting will be closed to the public, pursuant to 5 U.S.C. App. 2, section 10(d) and Public Law 103-202, 202(c)(1)(B)(31 U.S.C. 3121 note).</P>
                <P>This notice shall constitute my determination, pursuant to the authority placed in heads of agencies by 5 U.S.C. App. 2, section 10(d) and vested in me by Treasury Department Order No. 101-05, that the meeting will consist of discussions and debates of the issues presented to the Committee by the Secretary of the Treasury and the making of recommendations of the Committee to the Secretary, pursuant to Public Law 103-202, section 202(c)(1)(B).</P>
                <P>Thus, this information is exempt from disclosure under that provision and 5 U.S.C. 552b(c)(3)(B). In addition, the meeting is concerned with information that is exempt from disclosure under 5 U.S.C. 552b(c)(9)(A). The public interest requires that such meetings be closed to the public because the Treasury Department requires frank and full advice from representatives of the financial community prior to making its final decisions on major financing operations. Historically, this advice has been offered by debt management advisory committees established by the several major segments of the financial community. When so utilized, such a committee is recognized to be an advisory committee under 5 U.S.C. App. 2, section 3.</P>
                <P>Although the Treasury's final announcement of financing plans may not reflect the recommendations provided in reports of the Committee, premature disclosure of the Committee's deliberations and reports would be likely to lead to significant financial speculation in the securities market. Thus, this meeting falls within the exemption covered by 5 U.S.C. 552b(c)(9)(A).</P>
                <P>The Office of Debt Management is responsible for maintaining records of debt management advisory committee meetings and for providing annual reports setting forth a summary of Committee activities and such other matters as may be informative to the public consistent with the policy of 5 U.S.C. 552(b). The Designated Federal Officer or other responsible agency official who may be contacted for additional information is Fred Pietrangeli, Director for Office of Debt Management (202) 622-1876.</P>
                <SIG>
                    <DATED>Dated: January 4, 2024.</DATED>
                    <NAME>Frederick E. Pietrangeli,</NAME>
                    <TITLE>Director (for Office of Debt Management).</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-00218 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4810-25-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF VETERANS AFFAIRS</AGENCY>
                <DEPDOC>[OMB Control No. 2900-0394]</DEPDOC>
                <SUBJECT>Agency Information Collection Activity: Certification of School Attendance—Restored Entitlement Program for Survivors (REPS)</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Veterans Benefits Administration, Department of Veterans Affairs.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        Veterans Benefits Administration, Department of Veterans Affairs (VA), is announcing an opportunity for public comment on the proposed collection of certain information by the agency. Under the Paperwork Reduction Act (PRA) of 1995, Federal agencies are required to publish notice in the 
                        <E T="04">Federal Register</E>
                         concerning each proposed collection of information, including each proposed revision of a currently approved collection, and allow 60 days for public comment in response to the notice.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P> Written comments and recommendations on the proposed collection of information should be received on or before March 11, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Submit written comments on the collection of information through Federal Docket Management System (FDMS) at 
                        <E T="03">www.Regulations.gov</E>
                         or to Nancy J. Kessinger, Veterans Benefits Administration (20M33), Department of Veterans Affairs, 810 Vermont Avenue NW, Washington, DC 20420 or email to 
                        <E T="03">nancy.kessinger@va.gov.</E>
                         Please refer to “OMB Control No. 2900-0394” in any correspondence. During the comment period, comments may be viewed online through FDMS.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Maribel Aponte, Office of Enterprise and Integration, Data Governance Analytics (008), 810 Vermont Ave. NW, Washington, DC 20420, (202) 266-4688 or email 
                        <E T="03">maribel.aponte@va.gov.</E>
                         Please refer to “OMB Control No. 2900-0394” in any correspondence.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <PRTPAGE P="1148"/>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Under the PRA of 1995, Federal agencies must obtain approval from the Office of Management and Budget (OMB) for each collection of information they conduct or sponsor. This request for comment is being made pursuant to section 3506(c)(2)(A) of the PRA.</P>
                <P>With respect to the following collection of information, VBA invites comments on:  (1) whether the proposed collection of information is necessary for the proper performance of VBA's functions, including whether the information will have practical utility; (2) the accuracy of VBA's estimate of the burden of the proposed collection of information; (3) ways to enhance the quality, utility, and clarity of the information to be collected; and (4) ways to minimize the burden of the collection of information on respondents, including through the use of automated collection techniques or the use of other forms of information technology.</P>
                <P>
                    <E T="03">Authority:</E>
                     38 U.S.C. 5101.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Certification of School Attendance—REPS, 21P-8926.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     2900-0394.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension of a currently approved collection.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     VA Form 21P-0826 is primarily used to gather necessary information to determine a claimant's continued eligibility for REPS benefits. The information on the form is necessary to determine if the claimant is enrolled full-time in an approved school and are otherwise eligible under the REPS eligibility criteria. Without this information, determination of continued entitlement would not be possible. This is an extension with no changes to the form. The burden has not changed since last approval.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals and households.
                </P>
                <P>
                    <E T="03">Estimated Annual Burden:</E>
                     300 hours.
                </P>
                <P>
                    <E T="03">Estimated Average Burden per Respondent:</E>
                     15 minutes.
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     One time.
                </P>
                <P>
                    <E T="03">Estimated Number of Respondents:</E>
                     1,200.
                </P>
                <SIG>
                    <P>By direction of the Secretary.</P>
                    <NAME>Maribel Aponte,</NAME>
                    <TITLE>VA PRA Clearance Officer, Office of Enterprise and Integration/Data Governance Analytics, Department of Veterans Affairs.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-00216 Filed 1-8-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8320-01-P</BILCOD>
        </NOTICE>
    </NOTICES>
    <VOL>89</VOL>
    <NO>6</NO>
    <DATE>Tuesday, January 9, 2024</DATE>
    <UNITNAME>Proposed Rules</UNITNAME>
    <NEWPART>
        <PTITLE>
            <PRTPAGE P="1149"/>
            <PARTNO>Part II</PARTNO>
            <AGENCY TYPE="P"> Environmental Protection Agency</AGENCY>
            <CFR>40 CFR Parts 70 and 71</CFR>
            <TITLE>Clarifying the Scope of “Applicable Requirements” Under State Operating Permit Programs and the Federal Operating Permit Program; Proposed Rule</TITLE>
        </PTITLE>
        <PRORULES>
            <PRORULE>
                <PREAMB>
                    <PRTPAGE P="1150"/>
                    <AGENCY TYPE="S">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                    <CFR>40 CFR Parts 70 and 71</CFR>
                    <DEPDOC>[EPA-HQ-OAR-2023-0401; FRL-9118-01-OAR]</DEPDOC>
                    <RIN>RIN 2060-AV61</RIN>
                    <SUBJECT>Clarifying the Scope of “Applicable Requirements” Under State Operating Permit Programs and the Federal Operating Permit Program</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) proposes to update its title V operating permit program regulations to more clearly reflect the EPA's existing interpretations and policies concerning when and whether “applicable requirements” established in other Clean Air Act (CAA or the Act) programs should be reviewed, modified, and/or implemented through the title V operating permits program. Specifically, this action clarifies the limited situations in which requirements under the New Source Review (NSR) preconstruction permitting program would be reviewed using the EPA's unique title V oversight authorities. Additionally, this action clarifies that requirements related to an owner or operator's general duty to prevent accidental releases of hazardous substances are not “applicable requirements” for title V purposes and are not implemented through title V.</P>
                    </SUM>
                    <EFFDATE>
                        <HD SOURCE="HED">DATES:</HD>
                        <P>
                            <E T="03">Comments:</E>
                             Comments must be received on or before March 11, 2024. 
                            <E T="03">Public hearing:</E>
                             If anyone contacts the EPA requesting a public hearing by January 15, 2024, the EPA will hold a virtual public hearing. Please refer to the 
                            <E T="02">SUPPLEMENTARY INFORMATION</E>
                             section for additional information on requesting and registering for a public hearing.
                        </P>
                    </EFFDATE>
                    <ADD>
                        <HD SOURCE="HED">ADDRESSES:</HD>
                        <P>You may send comments, identified by Docket ID No. EPA-HQ-OAR-2023-0401, 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">Email: a-and-r-docket@epa.gov.</E>
                             Include Docket ID No. EPA-HQ-OAR-2023-0401 in the subject line of the message.
                        </P>
                        <P>
                            • 
                            <E T="03">Fax:</E>
                             (202) 566-9744. Attention Docket ID No. EPA-HQ-OAR-2023-0401.
                        </P>
                        <P>
                            • 
                            <E T="03">Mail:</E>
                             U.S. Environmental Protection Agency, EPA Docket Center, OAR 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, 
                            <E T="03">see</E>
                             the 
                            <E T="02">SUPPLEMENTARY INFORMATION</E>
                             section of this document.
                        </P>
                    </ADD>
                    <FURINF>
                        <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                        <P>
                            Mr. Matthew Spangler, Air Quality Policy Division, Office of Air Quality Planning and Standards (C504-05), Environmental Protection Agency, Research Triangle Park, NC; telephone number: (919) 541-0327; email address: 
                            <E T="03">spangler.matthew@epa.gov.</E>
                        </P>
                    </FURINF>
                </PREAMB>
                <SUPLINF>
                    <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                    <P>The Information presented in this document is organized as follows:</P>
                    <EXTRACT>
                        <FP SOURCE="FP-2">I. Public Participation in This Proposed Rulemaking</FP>
                        <FP SOURCE="FP1-2">A. Does this action apply to me?</FP>
                        <FP SOURCE="FP1-2">B. Where can I get a copy of this document and other related information?</FP>
                        <FP SOURCE="FP1-2">C. What should I consider as I prepare my comments?</FP>
                        <FP SOURCE="FP1-2">D. How do I request and participate in a virtual public hearing?</FP>
                        <FP SOURCE="FP-2">II. Purpose of This Regulatory Action</FP>
                        <FP SOURCE="FP-2">III. Background on Title V Operating Permits and CAA “Applicable Requirements”</FP>
                        <FP SOURCE="FP1-2">A. The Title V Permitting Process, Public Participation, and the EPA's Oversight Role</FP>
                        <FP SOURCE="FP1-2">B. Purpose and Function of Title V Permits</FP>
                        <FP SOURCE="FP1-2">C. Regulatory Definition of “Applicable Requirements”</FP>
                        <FP SOURCE="FP1-2">D. Requirements That Are Not “Applicable Requirements” for Purposes of Title V Permitting</FP>
                        <FP SOURCE="FP1-2">
                            E. Self-Implementing Applicable Requirements (
                            <E T="03">e.g.,</E>
                             NSPS, NESHAP)
                        </FP>
                        <FP SOURCE="FP1-2">F. Requirements Defined Through Title V Permitting</FP>
                        <FP SOURCE="FP1-2">G. Applicable Requirements Related to the NAAQS and SIPs</FP>
                        <FP SOURCE="FP-2">IV. Interface Between NSR and Title V Permitting</FP>
                        <FP SOURCE="FP1-2">A. Background: Historical and Current EPA Positions</FP>
                        <FP SOURCE="FP1-2">B. Proposed Action</FP>
                        <FP SOURCE="FP1-2">C. Interaction With NSR Permitting, Oversight, and Enforcement</FP>
                        <FP SOURCE="FP1-2">D. Impacts of Proposed Action</FP>
                        <FP SOURCE="FP1-2">E. Rationale for Proposed Action</FP>
                        <FP SOURCE="FP1-2">F. Alternative Approaches</FP>
                        <FP SOURCE="FP-2">V. The General Duty Clause Concerning the Prevention of Accidental Releases of Hazardous Substances</FP>
                        <FP SOURCE="FP1-2">A. Background and Summary of Proposed Action</FP>
                        <FP SOURCE="FP1-2">B. Rationale for Proposed Action</FP>
                        <FP SOURCE="FP-2">VI. Statutory and Executive Order Reviews</FP>
                        <FP SOURCE="FP1-2">A. Executive Order 12866: Regulatory Planning and Review, Executive Order 13563: Improving Regulation and Regulatory 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 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</FP>
                        <FP SOURCE="FP1-2">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</FP>
                        <FP SOURCE="FP-2">VII. Statutory Authority</FP>
                    </EXTRACT>
                    <HD SOURCE="HD1">I. Public Participation in This Proposed Rulemaking</HD>
                    <HD SOURCE="HD2">A. Does this action apply to me?</HD>
                    <P>Entities potentially affected by this proposed rulemaking include state, local, and Tribal air pollution control agencies that administer title V operating permit programs (“permitting authorities”), owners and operators of emissions sources in all industry groups who hold or apply for title V operating permits, and any person or group who participates in the title V permitting process.</P>
                    <HD SOURCE="HD2">B. Where can I get a copy of this document and other related information?</HD>
                    <P>
                        The EPA has established a docket for this rulemaking under Docket ID No. EPA-HQ-OAR-2023-0401. All documents in the docket pertaining to this action are listed on the 
                        <E T="03">https://www.regulations.gov</E>
                         website. Although listed in the index, some information may not be publicly available, 
                        <E T="03">e.g.,</E>
                         Confidential Business Information (CBI), Proprietary Business Information (PBI), or other information whose disclosure is restricted by statute. Certain other material, such as copyrighted material, is not placed on the internet and may be viewed with prior arrangement with the EPA Docket Center. In addition to being available in the docket, an electronic copy of this 
                        <E T="04">Federal Register</E>
                         document will be posted at 
                        <E T="03">https://www.epa.gov/title-v-operating-permits/current-regulations-and-regulatory-actions.</E>
                          
                        <PRTPAGE P="1151"/>
                        Additionally, a number of documents that are relevant to this proposed action—in particular, prior EPA orders responding to petitions challenging individual title V permits—are available through the EPA's website at 
                        <E T="03">https://www.epa.gov/title-v-operating-permits/title-v-petition-database.</E>
                    </P>
                    <HD SOURCE="HD2">C. What should I consider as I prepare my comments?</HD>
                    <P>
                        Submit your comments, identified by Docket ID No. EPA-HQ-OAR-2023-0401, 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. The EPA may publish any comment received to its public docket.
                    </P>
                    <P>
                        Do not submit information containing CBI to the EPA through 
                        <E T="03">https://www.regulations.gov.</E>
                         Clearly mark the part or all of the information that you claim to be CBI. For CBI information on any digital storage media that you mail to the EPA, mark the outside of the digital storage media as CBI and then identify electronically within the digital storage media the specific information that is claimed as CBI. In addition to one complete version of the comments that includes information claimed as CBI, you must submit a copy of the comments that does not contain the information claimed as CBI directly to the public docket through the procedures outlined in Instructions. If you submit any digital storage media that does not contain CBI, mark the outside of the digital storage media clearly that it does not contain CBI. Information not marked as CBI will be included in the public docket and the EPA's electronic public docket without prior notice. Information marked as CBI will not be disclosed except in accordance with procedures set forth in 40 Code of Federal Regulations (CFR) part 2. Our preferred method to receive CBI is for it to be transmitted electronically using email attachments, File Transfer Protocol (FTP), or other online file sharing services (
                        <E T="03">e.g.,</E>
                         Dropbox, OneDrive, Google Drive). Electronic submissions must be transmitted directly to the OAQPS CBI Office using the email address, 
                        <E T="03">oaqpscbi@epa.gov,</E>
                         and should include clear CBI markings as described later. If assistance is needed with submitting large electronic files that exceed the file size limit for email attachments, and if you do not have your own file sharing service, please email 
                        <E T="03">oaqpscbi@epa.gov</E>
                         to request a file transfer link. If sending CBI information through the postal service, please send it to the following address: OAQPS Document Control Officer (C404-02), OAQPS, U.S. Environmental Protection Agency, Research Triangle Park, North Carolina 27711, Attention Docket ID No. EPA-HQ-OAR-2023-0401. The mailed CBI material should be double wrapped and clearly marked. Any CBI markings should not show through the outer envelope.
                    </P>
                    <HD SOURCE="HD2">D. How do I request and participate in a virtual public hearing?</HD>
                    <P>
                        To request a virtual public hearing, contact Ms. Pam Long at (919) 541-0641 or by email at 
                        <E T="03">long.pam@epa.gov</E>
                         by January 15, 2024. If requested, the virtual hearing will be held on January 24, 2024. The hearing will convene at 9:00 a.m. Eastern Time (ET) and will conclude at 3:00 p.m. ET. The EPA may close a session 15 minutes after the last pre-registered speaker has testified if there are no additional speakers. The EPA will announce further details at 
                        <E T="03">https://www.epa.gov/title-v-operating-permits.</E>
                    </P>
                    <P>
                        Upon publication of this document in the 
                        <E T="04">Federal Register</E>
                        , the EPA will begin pre-registering speakers for the hearing, if a hearing is requested. To register to speak at the virtual hearing, please use the online registration form available at 
                        <E T="03">https://www.epa.gov/title-v-operating-permits</E>
                         or contact Ms. Pam Long at (919) 541-0641 or by email at 
                        <E T="03">long.pam@epa.gov.</E>
                         The last day to pre-register to speak at the hearing will be January 22, 2024. Prior to the hearing, the EPA will post a general agenda that will list pre-registered speakers in approximate order at: 
                        <E T="03">https://www.epa.gov/title-v-operating-permits.</E>
                    </P>
                    <P>The EPA will make every effort to follow the schedule as closely as possible on the day of the hearing; however, please plan for the hearing to run either ahead of schedule or behind schedule.</P>
                    <P>
                        Each commenter will have 3 minutes to provide oral testimony. The EPA encourages commenters to provide the EPA with a copy of their oral testimony electronically (via email) by emailing it to 
                        <E T="03">long.pam@epa.gov.</E>
                         The EPA also recommends submitting the text of your oral testimony as written comments to the rulemaking docket.
                    </P>
                    <P>The EPA may ask clarifying questions during the oral presentations but will not respond to the presentations at that time. Written statements and supporting information submitted during the comment period will be considered with the same weight as oral testimony and supporting information presented at the public hearing.</P>
                    <P>
                        Please note that any updates made to any aspect of the hearing will be posted online at 
                        <E T="03">https://www.epa.gov/title-v-operating-permits.</E>
                         While the EPA expects the hearing to go forward as set forth earlier, please monitor our website or contact Ms. Pam Long at (919) 541-0641 or by email at 
                        <E T="03">long.pam@epa.gov</E>
                         to determine if there are any updates. The EPA does not intend to publish a document in the 
                        <E T="04">Federal Register</E>
                         announcing updates.
                    </P>
                    <P>If you require the services of a translator or special accommodations such as audio description, please pre-register for the hearing with Ms. Pam Long and describe your needs by January 16, 2024. The EPA may not be able to arrange accommodations without advanced notice.</P>
                    <HD SOURCE="HD1">II. Purpose of This Regulatory Action</HD>
                    <P>This rulemaking concerns the relationship between the CAA's title V operating permit program and certain types of “applicable requirements” established under different sections of the CAA. Many of the EPA's past statements on this topic are included within the EPA Administrator's responses to citizen petitions challenging title V permits issued to individual facilities. Though publicly available, these Orders may not be widely read by members of the public and/or permitting authorities. This rulemaking is intended to bring greater awareness to the EPA's current approach to “applicable requirements” within the context of title V so that the public, permitting authorities, and the EPA can focus their resources on using the title V permitting process to address issues that can be most effectively resolved through title V. Specifically, this proposed rule addresses three issues that have been the source of public interest and, at times, misunderstanding. This rule also proposes to update the EPA's regulations to better express the EPA's existing positions on these topics.</P>
                    <P>
                        First, section III. of this preamble includes background on the EPA's existing position regarding general topics involving “applicable requirements,” which the EPA does not propose to change. In summary, the title V operating permit program is a vehicle for compiling air quality control requirements from other CAA programs and for providing conditions necessary to assure compliance with such requirements, but it is not a vehicle for creating or changing applicable requirements from those other programs. The EPA has a regulatory definition of the term “applicable requirement” that guides the interaction between title V and other CAA programs. Some programs establish “self-implementing” requirements that 
                        <PRTPAGE P="1152"/>
                        can be incorporated into title V permits without further review. Other programs contain only general requirements that can, in certain circumstances, be further defined through title V. Section III.G. of this preamble summarizes existing EPA positions about how these concepts affect requirements related to the National Ambient Air Quality Standards (NAAQS) and State Implementation Plans (SIPs).
                    </P>
                    <P>Second, Section IV. of this preamble addresses the intersection between title V operating permits and NSR preconstruction permits issued under title I of the CAA and focuses on the limited situations in which NSR requirements would be reviewed using the EPA's unique title V oversight authorities.</P>
                    <P>
                        Section IV.A. discusses the EPA's historical and current positions on the intersection between permits issued under title I and title V, which have changed over time. Section IV.B. explains in more detail the EPA's existing position, which the EPA proposes to codify through this rulemaking. In summary, the EPA's current position is that provided a source obtains an NSR permit under EPA-approved (or EPA-promulgated) title I rules, with public notice and the opportunity for comment and judicial review, such NSR permit establishes the NSR-related “applicable requirements” of the SIP (or Federal Implementation Plan, FIP) for purposes of incorporation into a title V permit. As with “applicable requirements” established under other CAA authorities, the EPA would not revisit those NSR permitting decisions through the title V process. The EPA's framework applies similarly regardless of: (i) the stage of the title V permitting or oversight process at issue; (ii) the NSR permit's origin (
                        <E T="03">i.e.,</E>
                         from a SIP or a FIP), (iii) the type of substantive NSR requirement at issue (
                        <E T="03">e.g.,</E>
                         NSR permit terms or major NSR applicability); and (iv) the procedures by which the NSR permit is incorporated into the title V permit (
                        <E T="03">e.g.,</E>
                         sequentially or concurrently issued permits). However, there are situations in which the title V permitting process is the appropriate venue for addressing NSR permitting issues, including where NSR requirements have not been established through a sufficient title I permitting process, or where NSR issues and title V issues involve substantive overlap. Although the EPA believes that the existing regulations may properly be read to support the EPA's existing position, the EPA proposes amendments to make this position more explicit. Updating the EPA's regulations will allow the agency to apply its existing approach nationwide and will resolve issues stemming from conflicting court decisions from two federal Courts of Appeals.
                    </P>
                    <P>Section IV.C. discusses the extent to which this proposal will (or will not) impact NSR permitting, NSR oversight tools, and NSR enforcement tools. Section IV.D. further discusses the limited impacts this proposed rule is expected to have on the EPA, permitting authorities, regulated entities, and the public. Overall, this proposed rule is meant to provide clarity about the appropriate mechanisms that should be used to address concerns with NSR permits. This proposed rule should create an incentive for permitting authorities to offer opportunities for meaningful public involvement in NSR permitting actions, and should encourage the public to take advantage of those opportunities (instead of attempting to use title V oversight tools to resolve concerns with NSR permits).</P>
                    <P>Section IV.E. details the EPA's legal and policy rationale for the EPA's existing (and proposed to be codified) position. In sum, the EPA's interpretation is supported by the text of title V, the structure and purpose of title V, and the structure of the CAA as a whole. The EPA has the discretion under the statute to apply this approach, which reflects better policy than alternative approaches. This proposed rule ensures that applicable requirements established in different CAA programs are treated consistently in title V permitting. The EPA's proposal better accounts for procedural, resource-related, and practical limitations associated with title V oversight tools while incentivizing the use of proper title I avenues of review. Lastly, this approach respects the finality of NSR permitting decisions.</P>
                    <P>Section IV.F. solicits comment on three alternative approaches that would involve using title V permits to address substantive NSR issues in additional, targeted situations, while explaining why these alternatives are not preferred by the EPA.</P>
                    <P>Third, Section V. of this preamble addresses a distinct and severable topic related to the “General Duty Clause” of CAA section 112(r)(1), which concerns the prevention of accidental releases of hazardous substances. This proposal seeks to codify the EPA's well-established position that this General Duty Clause is not an “applicable requirement” and is not implemented through title V.</P>
                    <HD SOURCE="HD1">III. Background on Title V Operating Permits and CAA “Applicable Requirements”</HD>
                    <P>
                        This section of the preamble contains background information about the title V program and explains how different types of “applicable requirements” of the CAA are treated in title V permits. This discussion is intended to clarify multiple related topics that may have been a source of confusion to the public, regulated entities, and permitting authorities over the years. The EPA is not proposing any changes to the agency's longstanding interpretations or policies discussed in this section. The EPA also considers these interpretations and policies to be consistent with, and accurately reflected in, the EPA's existing regulations in 40 CFR parts 70 and 71. Thus, the EPA is not proposing to revise the EPA's regulations in order to reflect these existing interpretations and policies.
                        <SU>1</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1</SU>
                             By contrast, the EPA is proposing to revise the EPA's regulations to more clearly reflect the EPA's positions regarding the issues discussed in sections IV. and V. of this preamble.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">A. The Title V Permitting Process, Public Participation, and the EPA's Oversight Role</HD>
                    <P>Congress amended the CAA in 1990 to add, among other provisions, title V. CAA Amendments of 1990, Public Law 101-549, sections 501-507, 104 Stat. 2399, 2635-48 (1990) (codified at 42 U.S.C. 7661-7661f). Title V established an operating permit program for major sources of air pollution and certain other sources.</P>
                    <P>
                        The title V program, like other provisions of the CAA, involves an exercise of cooperative federalism, meaning that responsibility for the program is divided between states and the EPA. Under title V, states were required to develop and submit to the EPA for approval title V permitting programs consistent with requirements promulgated by the EPA in 40 CFR part 70. 42 U.S.C. 7661a(b), (d).
                        <SU>2</SU>
                        <FTREF/>
                         Most states, certain local agencies, and one Tribe now have approved part 70 programs. Under these EPA-approved state programs, permitting authorities issue the vast majority of title V permits (this preamble refers to such permits as “state-issued” permits). The EPA directly issues title V permits only in limited circumstances.
                        <SU>3</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>2</SU>
                             For information about EPA oversight over the content and implementation of EPA-approved state part 70 programs, 
                            <E T="03">see</E>
                             42 U.S.C. 7661a(i) and 40 CFR 70.10.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>3</SU>
                             Under 40 CFR part 71, the EPA (or an agency delegated to issue permits on EPA's behalf) issues title V permits to sources in most areas of Indian Country, on the Outer Continental Shelf, 
                            <PRTPAGE/>
                            jurisdictions where the EPA has determined that a state has not adequately implemented its part 70 program, and for specific sources where a state has not satisfied an EPA objection to, or reopening of, a state-issued permit. 
                            <E T="03">See</E>
                             40 CFR 71.4.
                        </P>
                    </FTNT>
                    <PRTPAGE P="1153"/>
                    <P>
                        Most title V permit actions (including initial permits, renewal permits, and significant permit modifications) involve public notice and an opportunity for comment and a hearing on draft permits and revisions. 
                        <E T="03">See</E>
                         42 U.S.C. 7661a(b)(6); 40 CFR 70.4(d)(3)(iv), 70.7(h). These opportunities are similar to those provided in other CAA programs.
                    </P>
                    <P>
                        Additionally, Congress provided the EPA and the public with unique oversight tools for state-issued title V permits. The CAA requires permitting authorities to submit a proposed title V permit to the EPA Administrator for review for a 45-day review period before issuing the permit as final. 42 U.S.C. 7661d(a)(1); 40 CFR 70.8(a). The Administrator shall object to issuance of a proposed permit within that 45-day review period if the Administrator determines that the permit does not satisfy applicable requirements of the CAA or the requirements of part 70. 42 U.S.C. 7661d(b)(1); 40 CFR 70.8(c). If the Administrator does not object to a permit during the 45-day EPA review period, any person may petition the Administrator within 60 days after the expiration of the 45-day review period to take such action (hereinafter “title V petition” or “petition”). 42 U.S.C. 7661d(b)(2), 40 CFR 70.8(d), 70.12, 70.13, 70.14. Many of the issues concerning “applicable requirements” that are addressed in this rulemaking have been raised, and addressed, in title V petitions and the EPA's orders responding to such petitions.
                        <SU>4</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>4</SU>
                             For more information about title V petitions, 
                            <E T="03">see</E>
                             the preambles of the proposed and final petitions rule, 81 FR 57822 (Aug. 24, 2016) and 85 FR 6431 (Feb. 5, 2020). Copies of petitions and the EPA's petition orders are available on the EPA's public title V petitions database, 
                            <E T="03">https://www.epa.gov/title-v-operating-permits/title-v-petition-database.</E>
                        </P>
                    </FTNT>
                    <P>The CAA also provides the EPA with the authority—at the agency's discretion—to determine that cause exists to “terminate, modify, or revoke and reissue” a state-issued title V permit. 42 U.S.C. 7661d(e). This process is often called “reopening for cause” and is described in 40 CFR 70.7(f) and (g). Among other criteria, a permit may be reopened for cause when necessary to assure compliance with applicable requirements. 40 CFR 70.7(f)(1)(iv).</P>
                    <P>Although this proposed rule is primarily focused on the EPA's oversight of state-issued title V permits, the concepts discussed in this preamble related to “applicable requirements” are relevant to nearly all aspects of the title V permitting process in some shape or form. For example, these concepts guide the information that permittees must include in title V permit applications, the required content of title V permits drafted and issued by permitting authorities (including the EPA), the scope of issues properly subject to the public's input during the title V permitting process, and the scope of issues considered by the EPA in exercising its oversight roles (including the EPA's review of title V permits issued by states and consideration of citizen petitions on those permits).</P>
                    <HD SOURCE="HD2">B. Purpose and Function of Title V Permits</HD>
                    <P>The title V permitting program was created to assist with compliance and enforcement of air pollution controls established under other CAA programs. Before this program existed, the CAA pollution control requirements that might apply to a particular source could be found in many different provisions of the Act along with various federal and state regulations and permits. One court opinion summarized the relationship between title V and other CAA programs as follows:</P>
                    <EXTRACT>
                        <P>Under the regulatory regime established by the [CAA], emission limits for pollutants and monitoring requirements that measure compliance applicable to any given stationary source of air pollution are scattered throughout rules promulgated by states or EPA, such as [SIPs], new source performance standards [NSPS], and national emission standards for hazardous air pollutants [NESHAP]. Before 1990, regulators and industry were left to wander through this regulatory maze in search of the emission limits and monitoring requirements that might apply to a particular source. Congress addressed this confusion in the 1990 Amendments by adding title V of the Act, which created a national permit program that requires many stationary sources of air pollution to obtain permits that include relevant emission limits and monitoring requirements.</P>
                    </EXTRACT>
                    <FP>
                        <E T="03">Sierra Club</E>
                         v. 
                        <E T="03">EPA,</E>
                         536 F.3d 673, 674 (D.C. Cir. 2008) (citations omitted).
                    </FP>
                    <P>
                        Thus, one key function of title V is to consolidate applicable requirements established under other CAA programs. This consolidation function is embodied in CAA section 504(a), which states, in part: “Each permit issued under this subchapter shall include enforceable emission limitations and standards . . . and such other conditions as are necessary to assure compliance with applicable requirements of this chapter, including the requirements of the applicable implementation plan.” 42 U.S.C. 7661c(a). The EPA's regulations implementing title V contain language similar to the statute. 
                        <E T="03">See</E>
                         40 CFR 70.6(a)(1), 71.6(a)(1).
                        <SU>5</SU>
                        <FTREF/>
                         The EPA's regulations also require that “The permit shall specify and reference the origin of and authority for each term or condition, and identify any difference in form as compared to the applicable requirement upon which the term or condition is based.” 40 CFR 70.1(a)(1)(i), 71.1(a)(1)(i).
                    </P>
                    <FTNT>
                        <P>
                            <SU>5</SU>
                             The EPA's regulations also define the specific “applicable requirements” with which each title V permit must assure compliance. 40 CFR 70.2, 71.2. The definition and concept of “applicable requirements” are discussed in more detail later in this preamble.
                        </P>
                    </FTNT>
                    <P>
                        In addition to consolidating existing applicable requirements, CAA section 504 provides the EPA with the authority to use title V permits to establish additional requirements necessary to assure compliance with existing applicable requirements. For example, it is well established that title V permits may be used to create or supplement monitoring requirements when necessary in order to assure compliance with underlying applicable requirements that do not themselves contain sufficient monitoring provisions.
                        <SU>6</SU>
                        <FTREF/>
                         Various compliance assurance requirements are included within title V and the EPA's implementing regulations; not all are restricted to monitoring.
                        <SU>7</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>6</SU>
                             
                            <E T="03">See</E>
                             42 U.S.C. 7661c(c); 40 CFR 70.6(c)(1); 
                            <E T="03">Sierra Club</E>
                             v. 
                            <E T="03">EPA,</E>
                             536 F.3d 673, 674-45, 680 (D.C. Cir. 2008) (“Title V did more than require the compilation in a single document of existing applicable emission limits and monitoring requirements. It also mandated that `[e]ach permit issued under [Title V] shall set forth . . . monitoring . . . requirements to assure compliance with the permit terms and conditions.' . . . [T]he Act requires: a permitting authority may supplement an inadequate monitoring requirement so that the requirement will `assure compliance with the permit terms and conditions.' ” (citations omitted)); 
                            <E T="03">see also, e.g., In the Matter of CITGO Refining and Chemicals Co., L.P., West Plant,</E>
                             Order on Petition No. VI-2007-01 at 6-8 (May 28, 2009).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>7</SU>
                             
                            <E T="03">See</E>
                             42 U.S.C. 7661c(a), (b), (c); 40 CFR 70.6(a)(1), (a)(3), (c), 71.6(a)(1), (a)(3), (c); 
                            <E T="03">see also, e.g., In the Matter of Suncor Energy (U.S.A.), Inc., Commerce City Refinery, Plant 2 (East),</E>
                             Order on Petition Nos. VIII-2022-13 &amp; VIII-2022-14 at 13-17 (July 31, 2023) (
                            <E T="03">Suncor East Order</E>
                            ).
                        </P>
                    </FTNT>
                    <P>
                        Beyond title V's consolidation and compliance assurance functions, title V generally does not impose new pollution control requirements on sources or provide a vehicle to modify such requirements established under other CAA programs. Thus, the EPA's regulations expressly provide: “All sources subject to these regulations shall have a permit to operate that assures compliance by the source with all applicable requirements. While 
                        <E T="03">title V does not impose substantive new requirements,</E>
                         it does require that . . . certain procedural measures be adopted especially with respect to compliance.” 40 CFR 70.1(b) (emphasis added). For 
                        <PRTPAGE P="1154"/>
                        additional information about the purpose and function of title V, see section IV.E.2. of this preamble.
                    </P>
                    <P>In summary, the title V operating permit program is a vehicle for compiling air quality control requirements from other CAA programs and for providing requirements necessary to assure compliance with such requirements, but not for creating or changing applicable requirements. Put simply, title V is a catch-all, not a cure-all. The discussion throughout the remainder of this preamble builds upon these longstanding general principles, which the EPA does not propose to change through this rulemaking.</P>
                    <HD SOURCE="HD2">C. Regulatory Definition of “Applicable Requirements”</HD>
                    <P>
                        As previously explained, CAA section 504(a) requires that title V permits “include enforceable emissions limitations and standards . . . and such other conditions as are necessary to assure compliance with applicable requirements of this chapter, including the requirements of the applicable implementation plan.” 42 U.S.C. 7661c(a).
                        <SU>8</SU>
                        <FTREF/>
                         However, the term “applicable requirements” is not defined in the Act and the statute does not otherwise specify how to determine the “applicable requirements of this chapter” for a particular source. When the EPA developed regulations to implement the title V program, the agency specifically defined the term “applicable requirement” as it relates to title V permitting. This subsection of the preamble addresses general topics associated with this regulatory definition. The subsections that follow elaborate on these general concepts with more specific examples about how these concepts impact different types of requirements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>8</SU>
                             Similar requirements appear in other parts of title V. “Schedule of compliance. The term `schedule of compliance' means a schedule of remedial measures, including an enforceable sequence of actions or operations, leading to compliance with an applicable implementation plan, emission standard, emission limitation, or emission prohibition” 42 U.S.C. 7661(3). “Nothing in this subsection shall be construed to alter the applicable requirements of this chapter that a permit be obtained before construction or modification.” 42 U.S.C. 7661a(a). Permitting authorities “have adequate authority to . . . issue permits and assure compliance . . . with each applicable standard, regulation, or requirement under this chapter.” 42 U.S.C. 7661a(b)(5). The regulations to implement the program shall include a “requirement that the applicant submit with the application a compliance plan describing how the source will comply with all applicable requirements under this chapter.” 42 U.S.C. 7661b(b). However, like section 504, these sections do not specify the scope of the term “applicable requirements” or how the permitting authority or the EPA is to determine what the applicable requirements are for an individual source as part of its title V permit.
                        </P>
                    </FTNT>
                    <P>As an initial matter, it is important to recognize that “applicable requirement” is a legal term of art with a precise meaning that is unique to title V. Its meaning is closely aligned with the primary function of title V permits: to consolidate and assure compliance with the substantive requirements established under other CAA programs. Thus, in general, the EPA's definition of “applicable requirement” focuses on those substantive requirements of other CAA programs that must be incorporated into a source's title V permit, and with which the title V permit must assure compliance. This means that not all CAA requirements are considered “applicable requirements” for title V purposes. However, the fact that some CAA requirements are not considered “applicable requirements” for title V purposes does not diminish the independent enforceability or importance of those requirements. It simply means that those requirements are not primarily implemented or enforced using title V permits.</P>
                    <P>
                        The EPA's regulations define “applicable requirement” to mean “all of the of the following as they apply to emissions units in a part 70 source,” 
                        <SU>9</SU>
                        <FTREF/>
                         followed by a list of 13 types of CAA-based requirements that qualify. 40 CFR 70.2; 
                        <E T="03">see</E>
                         40 CFR 71.2 (similar definition).
                        <SU>10</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>9</SU>
                             This definition also indicates that requirements that have been promulgated or approved at the time of permit issuance, but with which the source is not yet required to comply, are applicable requirements that must be included in a title V permit. 40 CFR 70.2, 71.2. The EPA is not aware of any issues or confusion concerning this element of the definition, which is not discussed further in this preamble.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>10</SU>
                             The list includes, in summary, requirements from: (1) SIPs and FIPs under CAA title I; (2) preconstruction permits under CAA title I; (3) CAA section 111 (NSPS and existing source rules); (4) CAA section 112 (NESHAP); (5) title IV (acid rain); (6) CAA sections 504(b) or 114(a)(3) (certain types of enhanced monitoring); (7) CAA sections 126(a)(1) and (c) (interstate pollution); (8) CAA section 129 (solid waste incineration); (9) CAA section 183(e) (consumer and commercial products); (10) CAA section 193(f) (tank vessels); (11) CAA section 328 (outer continental shelf permits); (12) CAA title VI (stratospheric ozone); and (13) any NAAQS, but only as it would apply to temporary sources under CAA section 504(e).
                        </P>
                    </FTNT>
                    <P>
                        Perhaps the most straightforward aspect of this definition is that, in order to qualify as an “applicable requirement” for title V purposes, the requirement must be based on the CAA and, more specifically, one of the CAA sections specifically identified in this definition. Requirements that are not based on (
                        <E T="03">i.e.,</E>
                         derived from) the CAA are not “applicable requirements” of the CAA with which a title V permit must assure compliance. Further, not all CAA requirements qualify as “applicable requirements” for title V purposes. Some sections of the CAA were intentionally omitted from the list of 13 types of “applicable requirements” because these sections either do not apply to stationary sources that must obtain title V permits, or these sections are not implemented through title V for other reasons. See section III.D.2. of this preamble for more information.
                    </P>
                    <P>A similarly important definitional element is that “applicable requirements” only include the listed types of CAA requirements “as they apply to emission units in a part 70 source.” Requirements of the CAA that do not directly apply to a source's emission units are not “applicable requirements” for title V purposes, as discussed in section III.D.3. of this preamble.</P>
                    <P>Additionally, the requirements of title V itself (and the EPA's part 70 and 71 implementing regulations) are not technically considered “applicable requirements” but are nonetheless centrally important to title V permitting. See section III.D.4. of this preamble for more information.</P>
                    <P>
                        The definition of “applicable requirement” can also affect the manner in which requirements that 
                        <E T="03">are</E>
                         considered applicable requirements are implemented through title V. In summary, some applicable requirements can be described as “self-implementing.” Once established, those requirements should entail little to no review through the title V permitting process. Other applicable requirements may require further site-specific evaluation in order to define the precise requirements that apply to individual emission units. In certain circumstances, the latter type of applicable requirements may be further defined using the title V permitting process. These topics are discussed in more detail in sections III.E. and III.F. of this preamble.
                    </P>
                    <HD SOURCE="HD2">D. Requirements That Are Not “Applicable Requirements” for Purposes of Title V Permitting</HD>
                    <P>
                        Sources subject to title V may be subject to a variety of requirements both within and beyond the CAA. Not all of these requirements are “applicable requirements” that must be included in a title V permit and with which the title V permit must assure compliance. Requirements that are not applicable requirements fall into several categories, discussed in the following subsections.
                        <PRTPAGE P="1155"/>
                    </P>
                    <HD SOURCE="HD3">1. Requirements Not Derived From the CAA</HD>
                    <P>
                        Many sources subject to title V are also subject to federal laws beyond the CAA, including environmental laws administered by the EPA or other federal agencies (
                        <E T="03">e.g.,</E>
                         the Clean Water Act (CWA); Safe Drinking Water Act; Resource Conservation and Recovery Act (RCRA); Comprehensive Environmental Response, Compensation, and Liability Act; National Environmental Policy Act, Emergency Planning and Community Right-to-Know Act, Endangered Species Act, and other statutes). Other federal laws may also impact the decision-making of state permitting authorities (
                        <E T="03">e.g.,</E>
                         the Civil Rights Act of 1964). These other federal laws—including the statutes and any implementing regulations—are not “applicable requirements” for title V purposes. Such requirements do not need to be included in title V permits, and title V permits do not need to assure compliance with these requirements. Further, whether a permittee or permitting authority has satisfied those requirements is beyond the scope of issues that the EPA can address through its title V-based oversight authorities, including the EPA's objection authority and public petition opportunity.
                        <SU>11</SU>
                        <FTREF/>
                         This is self-evident from the plain language of the CAA and the EPA's regulations, which limit the EPA's objection authority to permits that “are not in compliance with the applicable requirements of [the CAA].” 42 U.S.C. 7661b(1), (2); 
                        <E T="03">see</E>
                         40 CFR 70.8(c)(1), 70.12(a)(2). Nonetheless, the EPA sometimes receives title V petitions requesting the EPA's objection to the issuance of operating permits on the basis of alleged violations of laws other than the CAA. The EPA has denied all of those petition claims.
                        <SU>12</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>11</SU>
                             The EPA's regulations provide that title V permit issuance may be coordinated with the issuance of permits under the CWA and RCRA, but that does not mean those other requirements are subject to review through title V. 40 CFR 70.1(e), 71.1(d).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>12</SU>
                             
                            <E T="03">See, e.g., In The Matter of Gateway Generating Station,</E>
                             Order on Petition No. IX-2013-1 at 12-14 (Oct. 15, 2014); 
                            <E T="03">In the Matter of Monroe Electric Generating Plant,</E>
                             Order on Petition No. 6-99-2 at 27 (June 11, 1999).
                        </P>
                    </FTNT>
                    <P>
                        Other federal authorities are sometimes invoked in the context of title V permitting (and in particular, title V petitions), including presidential executive orders. Because executive orders are not legally binding on state permitting authorities and are generally not based on the CAA, they do not establish “applicable requirements” that states must implement through title V permitting. Accordingly, the EPA has denied title V petition claims alleging that state permitting authorities failed to satisfy executive orders.
                        <SU>13</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>13</SU>
                             
                            <E T="03">See, e.g., In the Matter of AK Steel Dearborn Works,</E>
                             Order on Petition No. V-2016-16 at 17-19 (Jan. 15, 2021) (
                            <E T="03">AK Steel Order</E>
                            ); 
                            <E T="03">In the Matter of Orange Recycling and Ethanol Production Facility, Pencor-Masada Oxynol, LLC,</E>
                             Order on Petition No. II-2000-07 at 32-33 (May 2, 2001) (
                            <E T="03">Pencor-Masada I Order</E>
                            ). Note that federal executive orders may be more directly relevant to EPA-issued title V permits under part 71 (as well as other types of EPA-issued permits).
                        </P>
                    </FTNT>
                    <P>
                        Many state permitting authorities have air quality laws that are not derived from the CAA and/or are not included as part of an EPA-approved state program.
                        <SU>14</SU>
                        <FTREF/>
                         These “state-only” requirements are not, standing alone, enforceable by the EPA and are not applicable requirements for title V purposes. Thus, these requirements do not need to be included in title V permits, title V permits do not need to assure compliance with these requirements, and these requirements are beyond the scope of the EPA's title V oversight tools. For these reasons, the EPA has denied numerous title V petition claims alleging that title V permits fail to satisfy state-only laws and requirements.
                        <SU>15</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>14</SU>
                             This includes requirements that may be designed to implement a CAA requirement, but which the EPA has not yet approved (including SIPs, state plans under CAA section 111(d), and state programs under CAA section 112(l), and part 70 programs).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>15</SU>
                             
                            <E T="03">See, e.g., In the Matter of Salt River Project Agricultural Improvement &amp; Power District, Agua Fria Generating Station,</E>
                             Order on Petition No. IX-2022-4 at 14 (July 28, 2022) (
                            <E T="03">SRP Agua Fria Order</E>
                            ); In 
                            <E T="03">the Matter of Shintech, Inc.,</E>
                             Order on Petition at 14 (Sept. 10, 1997) (
                            <E T="03">Shintech I Order</E>
                            ).
                        </P>
                    </FTNT>
                    <P>
                        State permitting authorities may, at their discretion, include requirements based on state-only enforceable laws within title V permits, but they are required to designate such permit terms as “state-only” or “not federally enforceable.” 40 CFR 70.6(b)(2). Again, these requirements are not “applicable requirements” for purposes of title V permitting. Thus, from the EPA's perspective, properly labeled state-only permit terms are not considered part of the title V permit; they may be physically present in the document, but they are not legally present for purposes of federal enforceability and oversight. As such, these permit terms are not subject to the EPA's objection authority nor the title V petition process. 40 CFR 70.6(b)(2). The EPA has denied many title V petition claims challenging the content of state-only permit terms.
                        <SU>16</SU>
                        <FTREF/>
                         Note, however, that there are some limited situations in which state-only requirements intersect with title V requirements.
                        <SU>17</SU>
                        <FTREF/>
                         Additionally, the CAA requires states to provide the public with an opportunity to raise concerns with any conditions of a title V permit, including state-only conditions, through judicial review in state court systems. 
                        <E T="03">See</E>
                         42 U.S.C. 7661a(b)(6); 40 CFR 70.4(b)(3)(x)-(xii). This opportunity exists in parallel to the unique oversight authorities (
                        <E T="03">e.g.,</E>
                         the EPA's objection authority and public petition opportunity) that extend only to federally enforceable requirements of title V permits.
                    </P>
                    <FTNT>
                        <P>
                            <SU>16</SU>
                             
                            <E T="03">See, e.g., In the Matter of Harquahala Generating Station Project,</E>
                             Order on Petition at 5 (July 2, 2003) (
                            <E T="03">Harquahala Order</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>17</SU>
                             For example, the EPA has used and will use title V oversight tools to assess whether state laws should be considered federally enforceable “applicable requirements” with which a title V permit must assure compliance. 
                            <E T="03">See, e.g., In the Matter of Georgia-Pacific Consumer Operations LLC, Crossett Paper Operations,</E>
                             Order on Petition Nos. VI-2018-3 &amp; VI-2019-12 at 14-15 (Feb. 22, 2023). The EPA has also considered whether title V permit terms are appropriately designated as federally enforceable requirements or state-only requirements. 
                            <E T="03">See, e.g., In the Matter of ExxonMobil Corp., Baytown Chemical Plant,</E>
                             Order on Petition No. VI-2020-9 at 24-26 (Mar. 18, 2022) (
                            <E T="03">ExxonMobil Baytown Chemical Order</E>
                            ). Additionally, the EPA will consider whether state-only requirements or permit terms would impair the effectiveness or enforceability of applicable requirements or other federally enforceable title V permit terms. 
                            <E T="03">See, e.g., Harquahala Order</E>
                             at 5. Finally, note that any terms of a title V permit that are 
                            <E T="03">not</E>
                             designated as “state only” or “not federally enforceable” (or similar) become federally enforceable upon permit issuance and are subject to the part 70 requirements that govern federally enforceable terms of title V permits, including requirements related to monitoring, recordkeeping, and reporting. 40 CFR 70.6(b)(1)-(2); 
                            <E T="03">see, e.g., In the Matter of ExxonMobil Fuels &amp; Lubricant Co., Baton Rouge Refinery, Reforming Complex and Utilities Unit,</E>
                             Order on Petition Nos. VI-2020-4, VI-2020-6, VI-2021-1, &amp; VI-2021-2 at 16 &amp; 16 n.26 (Mar. 18, 2022).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">2. CAA Requirements That Are Not Specifically Identified in 40 CFR 70.2</HD>
                    <P>The CAA is a large and complex statute, composed of many different programs. Not all of these programs are implemented in the same manner through title V or establish “applicable requirements” for title V purposes.</P>
                    <P>
                        One notable example is title II of the CAA, which concerns emission standards for internal combustion engines in mobile sources and nonroad engines. Even if such emission units are located at a stationary source, they are not regulated as a stationary source because they are excluded from the definition of “stationary source.” 
                        <E T="03">See</E>
                         42 U.S.C. 7602(z).
                        <SU>18</SU>
                        <FTREF/>
                         Thus, title II requirements with which a stationary source must comply are not included within the EPA's title V-focused 
                        <PRTPAGE P="1156"/>
                        regulatory definition of “applicable requirement.”
                    </P>
                    <FTNT>
                        <P>
                            <SU>18</SU>
                             Questions sometimes arise regarding whether an internal combustion engine used at a stationary source should be considered a nonroad engine or a part of the stationary source. 
                            <E T="03">See, e.g.,</E>
                             42 U.S.C. 7550(10); 7602(z); 40 CFR 1068.30. This topic is beyond the scope of the current rulemaking.
                        </P>
                    </FTNT>
                    <P>
                        Other substantive CAA programs relevant to stationary sources are similarly not identified in the EPA's regulatory definition of “applicable requirement” for title V purposes because Congress did not intend for them to be implemented through the title V program. For further information about one example—the “General Duty Clause” concerning the prevention of accidental releases of hazardous substances under CAA section 112(r)(1)—
                        <E T="03">see</E>
                         section V. of this preamble. Another example is the Greenhouse Gas Reporting Program in 40 CFR part 98. That program applies to stationary sources and uses the authorities provided in CAA sections 114 and 208 to collect greenhouse gas emissions information, but it is not an applicable requirement for title V purposes. Similarly, the Air Emissions Reporting Requirements program in 40 CFR part 51, subpart A imposes information-gathering requirements that are generally not implemented through title V.
                    </P>
                    <P>
                        Some CAA provisions are more general in nature and do not impose substantive requirements that are incorporated into title V permits. For example, title III of the CAA includes general provisions related to a number of cross-cutting topics. 
                        <E T="03">See</E>
                         42 U.S.C. 7601-7628. Although some of these requirements may directly or indirectly impact title V permitting, most provisions within title III are not “applicable requirements” for title V purposes.
                        <SU>19</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>19</SU>
                             One notable exception is the Outer Continental Shelf permitting requirements under CAA section 328, 42 U.S.C. 7627, which are considered applicable requirements for title V purposes. 40 CFR 70.2, 71.2.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">3. Requirements That Do Not Apply to Emission Units</HD>
                    <P>
                        Not all requirements from CAA programs identified in the EPA's regulatory definition of “applicable requirement” are considered applicable requirements for title V purposes. This is because the definition only includes such requirements “as they apply to emission units in a part 70 source.” 40 CFR 70.2, 71.2. Applicable requirements generally include the substantive requirements from other provisions of the Act that dictate the ongoing operations of emission units at the source. After all, as the name of this program suggests, title V operating permits are fundamentally designed to specify the conditions under which a source's emission units must 
                        <E T="03">operate.</E>
                         Further, a key purpose of the title V program is to assure that 
                        <E T="03">the source</E>
                         complies with the requirements to which it is subject. 
                        <E T="03">See</E>
                         42 U.S.C. 7661a(a).
                    </P>
                    <P>
                        Therefore, requirements of the CAA that do not directly apply to individual emission units at a part 70 source are not “applicable requirements” for title V purposes. Many of the CAA provisions that do not apply to emission units at a title V source could be described as programmatic or procedural in nature. For example, CAA requirements that specify actions that the EPA must take in order to establish or oversee different CAA programs (such as promulgating rules, taking action on state rules, and other programmatic oversight activities) are not applicable requirements that need to be reflected in a source's title V permit.
                        <SU>20</SU>
                        <FTREF/>
                         Similarly, the CAA requires state air agencies to undertake various activities related to the establishment and implementation of different CAA programs, including attainment planning requirements (
                        <E T="03">e.g.,</E>
                         in developing SIPs).
                        <SU>21</SU>
                        <FTREF/>
                         State permitting authorities are also subject to various requirements (mostly procedural) related to the issuance of non-title V permits (
                        <E T="03">e.g.,</E>
                         NSR permits).
                        <SU>22</SU>
                        <FTREF/>
                         In general, the EPA does not believe that Congress intended the title V program to serve as a vehicle to catch or correct programmatic or procedural problems associated with the establishment of applicable requirements in other CAA programs.
                        <SU>23</SU>
                        <FTREF/>
                         Instead, again, the title V program was designed to ensure that regulated sources comply with all the substantive air pollution control requirements to which they are subject. Thus, to the extent these requirements only directly regulate EPA or state actions—and do not result in requirements directly applicable to emission units at a title V source—they are not applicable requirements for title V purposes.
                    </P>
                    <FTNT>
                        <P>
                            <SU>20</SU>
                             
                            <E T="03">See, e.g., In the Matter of Hu Honua Bioenergy Facility,</E>
                             Order on Petition No. IX-2011-1 at 6-7 (Feb. 7, 2014) (
                            <E T="03">Hu Honua I Order</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>21</SU>
                             
                            <E T="03">See, e.g., In the Matter of Exxon Chemical Americas, Baton Rouge Polyolefins Plant,</E>
                             Order on Petition No. 6-00-1 at 10-11 (Apr. 12, 2000).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>22</SU>
                             
                            <E T="03">See, e.g., In the Matter of Century Aluminum of South Carolina, Inc.,</E>
                             Order on Petition No. IV-2023-09 at 19-20 (November 2, 2023) (
                            <E T="03">Century Aluminum Order</E>
                            ). However, note that there are limited circumstances under which procedural issues associated with other CAA programs (namely, the issuance of NSR permits) may be implicated in title V. See section IV.B.5.a. of this preamble for further discussion.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>23</SU>
                             By contrast, issues related to the procedures used to issue a title V permit are of central relevance to the title V program, and the unique title V oversight tools available to the EPA and the public generally may be used to address those deficiencies. See section III.D.4. of this preamble for more information on such part 70 requirements.
                        </P>
                    </FTNT>
                    <P>
                        Also, the CAA contains many cross-cutting general provisions (
                        <E T="03">e.g.,</E>
                         in title III of the CAA) that are not considered applicable requirements because they do not directly apply to emission units at part 70 sources.
                        <SU>24</SU>
                        <FTREF/>
                         The same is true for various cross-cutting regulatory provisions. To the extent these provisions are relevant to the implementation or enforcement of the title V program, they are independently enforceable and do not need to be explicitly specified in a title V permit. One example that often arises in the context of title V petitions is that of “credible evidence.” EPA, states, and citizens can use any credible evidence to prove compliance and non-compliance with the CAA, including compliance and non-compliance with title V permits. 
                        <E T="03">See</E>
                         42 U.S.C. 7413(a), 7604(a)(1), 7604(f)(4); 62 FR 8314 (Feb. 24, 1997). The EPA has repeatedly held that title V permits need not include language affirmatively restating the existence of this principle.
                        <SU>25</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>24</SU>
                             These general provisions are not considered applicable requirements for two reasons: (i) they are not specified within the regulatory definition's list of 13 types of CAA requirements (as discussed in the preceding subsection of the preamble), and (ii) they do not apply to emission units at a source (as discussed in this subsection).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>25</SU>
                             
                            <E T="03">See, e.g., In the Matter of Plains Marketing LP and Four Other Facilities,</E>
                             Order on Petition Nos. IV-2023-1 &amp; IV-2023-3 at 50 (Sept. 18, 2023). Note that EPA has also indicated that title V permits cannot be drafted in such a way that would preclude the use of all credible evidence in enforcement proceedings. 
                            <E T="03">See, e.g., In the Matter of Valero Refining-Texas, L.P., Valero Houston Refinery,</E>
                             Order on Petition No. VI-2021-8 at 70 (June 30, 2022) (
                            <E T="03">Valero Houston Order</E>
                            ).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">4. “Part 70 Requirements”</HD>
                    <P>
                        As previously stated, the definition of “applicable requirement” in 40 CFR 70.2 and 71.2, and the manner in which this phrase is used throughout the EPA's title V regulations, focus on CAA requirements arising from 
                        <E T="03">other</E>
                         CAA programs beyond title V. By contrast, the requirements within title V and the EPA's part 70 and 71 regulations are not technically considered “applicable requirements.” 
                        <SU>26</SU>
                        <FTREF/>
                         Instead, the EPA generally refers to these as “part 70 requirements.” 
                        <SU>27</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>26</SU>
                             Part 70 requirements do not meet the regulatory definition of “applicable requirement” because they are not included within the definition's list of 13 types of CAA requirements. Moreover, some part 70 requirements (
                            <E T="03">e.g.,</E>
                             procedural requirements) do not directly apply to emission units.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>27</SU>
                             The phrase “part 70 requirements” is based on various portions of the part 70 regulations that refer to the “requirements of this part” as a distinct, and additional, source of requirements from “applicable requirements” based on other CAA programs. 
                            <E T="03">See</E>
                             40 CFR 70.4(b)(3)(v), 70.6(a)(9)(iii), 70.6(a)(10)(iii), 70.7(a)(1)(iv), 70.8(b)(2), 70.8(c)(1), 70.12(a)(2). This concept is also relevant with respect to EPA-issued permits under 40 CFR part 71, where a similar distinction exists between “applicable 
                            <PRTPAGE/>
                            requirements” derived from other CAA programs and the requirements of part 71 that are derived from title V of the Act. 
                            <E T="03">See, e.g.,</E>
                             40 CFR 71.10(g)(1). However, given that this issue most often arises in the context of state-issued part 70 permits, this preamble uses the term “part 70 requirements” to refer to requirements derived from title V.
                        </P>
                    </FTNT>
                    <PRTPAGE P="1157"/>
                    <P>This distinction is meaningful because the regulatory use of the term “applicable requirement” is closely tied to the core purpose of title V: to consolidate and assure compliance with the substantive requirements from other CAA programs, but not to create or modify such requirements. Thus, as previously described, the title V permitting process and title V oversight tools are generally not used to reevaluate the content of “applicable requirements” from other CAA programs.</P>
                    <P>
                        By contrast, many “part 70 requirements” are directly implemented through title V permitting, as these requirements relate to the content of title V permits and the process used to issue them. For example, the requirements that dictate the content of title V permits are part 70 requirements (not applicable requirements). These include, for example, the requirement that title V permits include and assure compliance with “applicable requirements” established elsewhere, and the authority to impose, as necessary, additional monitoring and other compliance assurance provisions. 
                        <E T="03">See, e.g.,</E>
                         40 CFR 70.6(a), (c). Further, the requirements related to public participation in title V permits, the availability of information, and related procedural requirements are all part 70 requirements (not applicable requirements). 
                        <E T="03">See</E>
                         40 CFR 70.7(h). Title V and the part 70 regulations contain other unique title V authorities—such as the “permit shield” under CAA section 504(f) and 40 CFR 70.6(f).
                        <SU>28</SU>
                        <FTREF/>
                         The important distinction between these part 70 requirements and applicable requirements from other CAA programs is that part 70 requirements are properly subject to the additional oversight mechanisms unique to title V (including the EPA objection authority, public petition opportunity, and other programmatic oversight authorities).
                    </P>
                    <FTNT>
                        <P>
                            <SU>28</SU>
                             The permit shield is discussed in more detail in section IV.C.3. of this preamble to the extent it impacts NSR permitting decisions.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">E. Self-Implementing Applicable Requirements (e.g., NSPS, NESHAP)</HD>
                    <P>
                        Turning to CAA provisions that 
                        <E T="03">are</E>
                         considered “applicable requirements,” not all applicable requirements are treated the same in title V permits. This subsection addresses applicable requirements with the most straightforward title V implementation, often referred to as “self-implementing” or “self-executing” requirements. The hallmark of a self-implementing requirement is that the underlying statutory or regulatory provision defines the requirements applicable to a given emission unit with enough specificity for these requirements to be independently and immediately enforceable, even before going through the permitting process.
                        <SU>29</SU>
                        <FTREF/>
                         In other words, these applicable requirements require no further case-specific decisionmaking (
                        <E T="03">e.g.,</E>
                         through a permitting process) in order to define the precise requirements to which a source is subject. Such requirements consist of prescribed emission standards, operational limitations, testing, monitoring, recordkeeping, reporting, and other compliance assurance requirements. These requirements are explicitly identified within an EPA regulation (
                        <E T="03">e.g.,</E>
                         NSPS under CAA section 111, NESHAP under CAA section 112, Federal Plan under CAA section 111(d), similar rules under CAA section 129, or a FIP under CAA section 110(c)) or an EPA-approved state regulation (
                        <E T="03">e.g.,</E>
                         SIP under CAA section 110(a) or a State Plan under CAA sections 111(d) or 129).
                    </P>
                    <FTNT>
                        <P>
                            <SU>29</SU>
                             This is in contrast with some other programs the EPA administers, such as certain requirements under the CWA. Some new requirements under the CWA only become effective once they are incorporated into a source's National Pollutant Discharge Elimination System (NPDES) permit. 
                            <E T="03">See, e.g., Texas Oil &amp; Gas Ass'n et al</E>
                             v. 
                            <E T="03">US EPA,</E>
                             161 F.3d 923, 928 (5th Cir. 1998) (“Despite their central role in the framework of the CWA, [Effluent Limitation Guidelines, or ELGs] are not self-executing. They cannot be enforced against individual dischargers, and individual dischargers are under no legal obligations to obey limits set by ELGs. Rather, ELGs achieve their bite only after they have been incorporated into NPDES permits.” (citing 
                            <E T="03">American Paper Inst.</E>
                             v. 
                            <E T="03">EPA,</E>
                             996 F.2d 346, 350 (D.C. Cir. 1993); 
                            <E T="03">American Petroleum Inst.,</E>
                             661 F.2d 340, 344 (5th Cir. 1981)).
                        </P>
                    </FTNT>
                    <P>
                        Such self-implementing applicable requirements should generally be included in, or incorporated into, a title V permit without further review.
                        <SU>30</SU>
                        <FTREF/>
                         It would not be appropriate, for example, to use the title V permitting process to reevaluate the stringency of a Maximum Achievable Control Technology (MACT) standard promulgated by the EPA through rulemaking under CAA section 112.
                        <SU>31</SU>
                        <FTREF/>
                         The same is true with respect to the content of self-implementing standards contained in SIPs, as discussed further in section III.G. of this preamble.
                    </P>
                    <FTNT>
                        <P>
                            <SU>30</SU>
                             The manner in which such requirements may be included in or incorporated by reference into, a title V permit is beyond the scope of this rulemaking. For more information about incorporation by reference, 
                            <E T="03">see,</E>
                             for example, 
                            <E T="03">ExxonMobil Baytown Chemical Order</E>
                             at 16-19 and 
                            <E T="03">White Paper Number 2 for Improved Implementation of the Part 70 Operating Permits Program,</E>
                             36-41 (Mar. 5, 1996).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>31</SU>
                             
                            <E T="03">See, e.g., In the Matter of Borden Chemical, Inc. Formaldehyde Plant,</E>
                             Order on Petition No. 6-01-1 at 48-49 (Dec. 22, 2000).
                        </P>
                    </FTNT>
                    <P>
                        Central to the concept of “applicable requirements” is the fact that each applicable requirement is established through its own dedicated process, which includes the ability for the public to participate in the development of and, if necessary, challenge the substantive sufficiency of the requirement. For example, the EPA regulations referenced in preceding paragraphs are generally undertaken under CAA section 307, which establishes various procedural and public participation-related requirements, as well as the opportunity for judicial review of final regulations. 
                        <E T="03">See</E>
                         42 U.S.C. 7607(b)-(d). The promulgation and approval of SIPs often involves two such rulemakings—one at the state level and one at the federal level. Thus, the fact that self-implementing applicable requirements are not substantively re-evaluated through title V does not mean the public is without recourse; it simply means that the title V permitting process was not designed to collaterally attack or reopen these previously-finalized applicable requirements.
                    </P>
                    <P>
                        Given title V's key role in consolidating applicable requirements, questions often arise during the permitting process as to which CAA requirements are applicable to a given source or emission unit. To the extent that applicability is clearly established within the applicable requirement itself (
                        <E T="03">e.g.,</E>
                         a source-specific SIP provision) or some other type of final agency action (
                        <E T="03">e.g.,</E>
                         a formal EPA applicability determination under CAA sections 111, 112, or 129), applicability would not be subject to further scrutiny through title V.
                        <SU>32</SU>
                        <FTREF/>
                         However, there are cases where the applicability of a requirement—including a requirement that could otherwise be described as “self-implementing”—has not been conclusively established prior to title V permit issuance. In these cases, the title V permitting process can and should be used to determine which requirements apply to the source, so that the title V permit can include and assure compliance with those requirements. For example, determining which NSPS 
                        <PRTPAGE P="1158"/>
                        or NESHAP subpart is applicable to a source may require further site-specific factual analysis through the permitting process. Additionally, within a given NSPS or NESHAP rule, there may be multiple different sets of requirements that apply differently to emission units with different characteristics. In these situations, it may be necessary to use the title V permitting process to decide (and identify) which specific requirements within a NSPS or NESHAP rule apply to each emission unit at a source. In these cases, the title V permitting process can and should be used to determine which requirements apply to the source, so that the title V permit can include and assure compliance with those requirements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>32</SU>
                             The EPA has established formal and informal processes for EPA to resolve questions regarding the applicability of NSPS, NESHAP, and section 111(d) and section 129 rules, called the “applicability determination” process. 
                            <E T="03">See</E>
                             40 CFR 60.5, 61.06, 62.02(b)(2); 
                            <E T="03">EPA Process Manual for Responding to Requests Concerning Applicability and Compliance Requirements of Certain Clean Air Act Stationary Source Programs,</E>
                             Appx B (July 2020), available at 
                            <E T="03">https://www.epa.gov/sites/default/files/2020-07/documents/111-112-129_process_manual.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        Finally, even for self-implementing applicable requirements, the title V permitting process may be used to determine whether additional compliance assurance provisions (
                        <E T="03">e.g.,</E>
                         monitoring) are necessary. 
                        <E T="03">See</E>
                         42 U.S.C. 7661c(c); 40 CFR 70.6(c)(1); 
                        <E T="03">Sierra Club</E>
                         v. 
                        <E T="03">EPA,</E>
                         536 F.3d at 680. Further guidance on determining the sufficiency of monitoring and other compliance assurance provisions is beyond the scope of this rulemaking.
                    </P>
                    <HD SOURCE="HD2">F. Requirements Defined Through Title V Permitting</HD>
                    <P>
                        Although title V generally does not 
                        <E T="03">impose</E>
                         substantive new requirements, title V permits sometimes serve as the vehicle to further 
                        <E T="03">define</E>
                         applicable requirements from other CAA programs. This most often occurs when the underlying applicable requirement provides general direction and requires further source-specific analysis to define the precise requirements that apply to a given source or emission unit. Some underlying applicable requirements expressly identify title V permits as the vehicle for this analysis; others may be more open-ended about the vehicle used to define the applicable requirement; and still others may specify a different vehicle for establishing these requirements (
                        <E T="03">e.g.,</E>
                         NSR permits, discussed further in section IV. of this preamble).
                    </P>
                    <P>
                        Unlike applicable requirements that are established in full elsewhere, where the details of an applicable requirement are defined for the first time through the title V permitting process, questions about the content of such an applicable requirement 
                        <E T="03">are</E>
                         subject to title V's unique oversight tools, including the EPA's objection authority and the public petition opportunity.
                    </P>
                    <P>
                        For example, CAA section 112(g) requires the development of case-by-case Maximum Achievable Control Technology (MACT) limits prior to certain construction activities at a major source of HAPs where there is no NESHAP under CAA section 112(d).
                        <SU>33</SU>
                        <FTREF/>
                         These limits can—and in some cases, must—be established through the title V process. In such cases where a title V permit is used to establish a case-by-case MACT limit, questions about both the applicability and the content of such a limit (
                        <E T="03">i.e.,</E>
                         whether the limit properly reflects MACT) 
                        <E T="03">are</E>
                         subject to the unique oversight tools of title V.
                        <SU>34</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>33</SU>
                             Under CAA section 112(g)(2), if the EPA has not established a MACT standard for a source category, the EPA or the state must establish a case-by-case MACT emission limit prior to certain construction activities at a major source of HAPs. Similarly, under CAA section 112(j)(2), if the EPA has not established a MACT standard for a source category, a new or existing major source's title V operating permit must include a case-by-case MACT limit. 
                            <E T="03">See also</E>
                             40 CFR 63.40-44 (implementing regulations for 112(g)), 63.50-56 (implementing regulations for 112(j)).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>34</SU>
                             
                            <E T="03">See</E>
                             61 FR 68384, 68393, 68395 (Dec. 27, 1996) (“Where EPA determines that the MACT determination made by the permitting authority fails to meet any of the requirements of § 63.43 [and] where the MACT determination is made part of a source's part 70 permit, EPA may veto issuance of the permit in accordance with the provisions of 40 CFR 70.8(c).”); 
                            <E T="03">id.</E>
                             at 68395 (“If, during the EPA's review of the section 112(g) determination, it becomes apparent that the determination is not in compliance with the Act, then EPA must object to the issuance or revision of that permit.”); 
                            <E T="03">In the Matter of American Electric Power Service Corp., Southwest Electric Power Co., John W. Turk Plant,</E>
                             Order on Petition No. VI-2008-01 at 15-16 (Dec. 15, 2009); 
                            <E T="03">In the Matter of Shintech Inc., PVC Plant,</E>
                             Order on Petition No. 6-03-1 at 16-21 (July 3, 2003).
                        </P>
                    </FTNT>
                    <P>
                        Other requirements of CAA section 112 NESHAP and section 111 NSPS regulations may require further definition through, for example, various types of site-specific operational plans. These plans are generally developed outside of the title V permitting process, but to the extent they are necessary to impose or assure compliance with an applicable requirement of the NSPS or NESHAP, they must be included or incorporated into title V permits.
                        <SU>35</SU>
                        <FTREF/>
                         The title V permitting process may also be used for similar case-by-case decisions based on underlying SIP provisions, as discussed further in the following subsection of this preamble.
                    </P>
                    <FTNT>
                        <P>
                            <SU>35</SU>
                             Other requirements of CAA section 111 NSPS and section 112 NESHAP regulations may require further definition through various types of site-specific operational plans. These plans are generally developed outside of the title V permitting process, but to the extent they are necessary to impose or assure compliance with an applicable requirement of the NSPS or NESHAP, they must be included or incorporated into title V permits. 
                            <E T="03">See, e.g., Valero Houston Order</E>
                             at 25-26.
                        </P>
                    </FTNT>
                    <P>In these situations, it is not the title V permit that establishes the applicable requirement itself. The applicable requirement is still based on the underlying statutory or regulatory provision, but the title V permit defines the precise details of the applicable requirement. Essentially, the title V permitting process is used to develop the specific “enforceable emission limitations and standards . . . and such other conditions as are necessary to assure compliance with the [more general underlying] applicable requirements. . . .” 42 U.S.C. 7661c(a). Absent an underlying CAA-based authority, title V permits should generally not be used to impose new substantive requirements. 40 CFR 70.1(b).</P>
                    <HD SOURCE="HD2">G. Applicable Requirements Related to the NAAQS and SIPs</HD>
                    <P>
                        CAA requirements associated with the NAAQS and SIPs reflect the full spectrum of issues discussed in the preceding subsections of this preamble. Some are not applicable requirements for title V purposes; others are self-implementing applicable requirements that need no further review during title V; still others may be defined through title V permitting; and many are established in the NSR permitting process. Perhaps due to the variability and complexity of issues related to the NAAQS and SIPs, the EPA has received numerous title V petitions raising concerns that the EPA was not able to address through that mechanism. The EPA hopes that the following discussion will help reduce confusion about the issues that are—and are not—redressable through title V oversight tools.
                        <SU>36</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>36</SU>
                             As with essentially all other portions of this preamble, the explanations in this section reflect existing policies, as expressed in prior rule preambles, guidance documents, and numerous title V petition orders.
                        </P>
                    </FTNT>
                    <P>
                        Beginning with the NAAQS, it is well-established that the NAAQS are not themselves applicable requirements because they do not apply directly to sources.
                        <SU>37</SU>
                        <FTREF/>
                         That is, the promulgation of a NAAQS does not, in and of itself, automatically result in emission limits or other control measures applicable to a source. Instead, the NAAQS create an obligation on 
                        <E T="03">states</E>
                         to develop SIPs (and on EPA to promulgate FIPs, as necessary) that contain requirements necessary to achieve and maintain the NAAQS. 42 U.S.C. 7410(a)(1), (c)(1). 
                        <PRTPAGE P="1159"/>
                        The specific measures contained in each state's EPA-approved SIP to achieve the NAAQS are the applicable requirements with which sources must comply. 40 CFR 70.2. For purposes of title V permitting, this means that a state does not have any general obligation to establish emission limitations or other standards within a title V permit in order to protect the NAAQS. Whether such requirements are necessary is largely dependent on the relevant terms of the SIP.
                    </P>
                    <FTNT>
                        <P>
                            <SU>37</SU>
                             40 CFR 70.2 (defining “applicable requirement” to include the NAAQS “but only as it would apply to temporary sources”); 57 FR at 32276 (“Under the Act, NAAQS implementation is a requirement imposed on States in the SIP; it is not imposed directly on a source. In its final rule, EPA clarifies that the NAAQS and the increment and visibility requirements under part C of title I of the Act are applicable requirements for temporary sources only.”); 56 FR at 21732-33 (“The EPA does not interpret compliance with the NAAQS to be an `applicable requirement' of the Act.”).
                        </P>
                    </FTNT>
                    <P>
                        Some applicable requirements in SIPs could be described as “self-implementing” in a manner similar to the EPA's NSPS and NESHAP standards discussed in section III.E. of this preamble. For example, a source-specific SIP provision may impose a specific numerical emission limit or operational limit on a specific source. Or, a SIP provision, “permit by rule,” or “general permit” within the SIP may impose similar requirements on a category of sources or emission units. Such requirements should be included in the source's title V permit without further review (except, of course, to ensure that the permit contains sufficient monitoring and other compliance assurance conditions). Nonetheless, the EPA has received many title V petitions challenging such requirements contained in an EPA-approved SIP. Some petitions have directly challenged the SIP provision itself, asserting that the SIP requirement was incorrectly established or failed to satisfy certain legal requirements governing SIPs. More often, petitions have challenged permit terms that repeat verbatim an approved SIP provision; such claims effectively challenge the SIP itself. As the EPA has explained, if an alleged problem lies with the content of the SIP, the proper remedy would be a “SIP Call” under CAA section 110(k), not a title V petition. Until the EPA approves a corrective SIP revision or issues a FIP, the SIP provision remains an “applicable requirement” that should be incorporated unchanged into the title V permit. The EPA has consistently denied title V petition claims on this basis.
                        <SU>38</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>38</SU>
                             
                            <E T="03">See, e.g., In the Matter of Piedmont Green Power,</E>
                             Order on Petition Number IV-2015-2 at 28-29 (Dec. 13, 2016) (
                            <E T="03">Piedmont Green Power Order</E>
                            ); 
                            <E T="03">In the Matter of Pacificorp's Jim Bridger and Naughton Electric Utility Steam Generating Plants,</E>
                             Order on Petition No. VIII-00-1 at 23-24 (Nov. 16, 2000).
                        </P>
                    </FTNT>
                    <P>
                        Other SIP requirements are less specific and must be further defined in subsequent proceedings (generally before the state) that involve a fact-specific analysis of the relevant affected sources and emission units.
                        <SU>39</SU>
                        <FTREF/>
                         Depending on the nature of the SIP provisions at issue, this analysis may involve, for example, various methods of qualitatively or quantitatively assessing a source's impact on the NAAQS (including, but not limited to, ambient air dispersion modeling). This analysis may also result in case-by-case emission limits designed to protect the NAAQS. Determining the proper venue for satisfying or defining these general SIP requirements depends on the specific language contained in the SIP, as discussed in the following paragraphs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>39</SU>
                             
                            <E T="03">See, e.g.,</E>
                             56 FR at 21757 (“Where SIP requirements are clear, the part 70 permit must adopt these limitations and reestablish them as permit conditions that implement the SIP. Where the SIP requirements are ambiguous or absent, the permit could provide a way of resolving questions as to how the SIP applies and is enforced.”).
                        </P>
                    </FTNT>
                    <P>
                        In general, most SIP provisions provide that case-by-case decisions necessary to fulfill general SIP requirements will proceed either through subsequent rulemaking actions 
                        <SU>40</SU>
                        <FTREF/>
                         or through the NSR permitting process (as discussed in section IV. of this preamble). Once established, the more specific requirements of the SIP, as defined through those processes, are generally not subject to further review during the title V permitting process.
                    </P>
                    <FTNT>
                        <P>
                            <SU>40</SU>
                             
                            <E T="03">See, e.g., In the Matter of TransAlta Centralia Generation, LLC,</E>
                             Order on Petition at 11-12 (Apr. 28, 2011).
                        </P>
                    </FTNT>
                    <P>
                        However, some SIP requirements may be defined for the first time in a title V permit, in which case the contents of these requirements 
                        <E T="03">are</E>
                         reviewable using the unique title V oversight tools. Again, whether a SIP-based requirement is reviewable through the title V process depends on the specific SIP provision at issue. For example, the EPA has reviewed (and granted) title V petitions requesting analysis of a source's impacts on the NAAQS or case-specific emission limits designed to protect the NAAQS in situations where the SIP provisions at issue specifically suggested that such requirements would be implemented through title V.
                        <SU>41</SU>
                        <FTREF/>
                         In such cases, the EPA has generally provided the permitting authority the opportunity to interpret the relevant SIP provisions and to explain the scope, timing, and applicability of these provisions as they relate to the source in question.
                    </P>
                    <FTNT>
                        <P>
                            <SU>41</SU>
                             
                            <E T="03">See In the Matter of In the Matter of Alabama Power Co., Barry Generating Plant,</E>
                             Order on Petition No. IV-2021-5 at 11-14 (June 14, 2022) (granting a claim related to a SIP provision that required owner/operators of a certain type of source to “[d]emonstrate, to the satisfaction of the [state], that sulfur oxides emitted, either alone or in contribution to other sources, will not interfere with attainment and maintenance of any primary or secondary [NAAQS]”); 
                            <E T="03">In the Matter of Duke Energy, LLC, Asheville Steam Electric Plant,</E>
                             Order on Petition No. IV-2016-06 at 11-17 (June 30, 2017) (granting claim related to a SIP requirement that “the permit shall contain a condition requiring” controls more stringent than the applicable emission standards when necessary to prevent a violation of the NAAQS—a provision the state had previously relied upon to establish limits in individual permits); 
                            <E T="03">In the Matter of Duke Energy, LLC, Roxboro Steam Electric Plant,</E>
                             Order on Petition No. IV-2016-07 at 10-15 (June 30, 2017) (same as 
                            <E T="03">Duke Asheville</E>
                            ); 
                            <E T="03">In the Matter of Public Service of New Hampshire, Schiller Station,</E>
                             Order on Petition No. VI2014-04 at 8-13 (July 28, 2015) (granting claim related to a SIP requirement to “apply special emission limits to the stationary sources on a case-by-case basis to insure [
                            <E T="03">sic</E>
                            ] that their air quality impacts” do not interfere with NAAQS attainment in adjacent states).
                        </P>
                    </FTNT>
                    <P>
                        The EPA has also addressed other, more general SIP provisions that do not explicitly require any specific action during the title V process. These provisions often take the form of broad, general prohibitions on air pollution, and these SIP provisions are not always directly tied to the NAAQS or any specific federal requirements. The EPA has explained that states have discretion under these general SIP provisions to determine that it is not necessary to impose source-specific limits through title V permits.
                        <SU>42</SU>
                        <FTREF/>
                         However, this does not prevent states from using title V to address such general requirements.
                        <SU>43</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>42</SU>
                             
                            <E T="03">See In the Matter of EME Homer City Generation LP and First Energy Generation Corp.,</E>
                             Order on Petition Nos. III2012-06, III-2012-07, and III-2013-02 at 15-16 (July 30, 2014) (SIP provision stated “No person may permit air pollution as that term is defined in the act”); 
                            <E T="03">In the Matter of TransAlta Centralia Generation, LLC,</E>
                             Order on Petition at 7 (April 28, 2011) (SIP provision prohibited “emissions detrimental to persons or property”); 
                            <E T="03">In the Matter of Hercules, Inc.,</E>
                             Order on Petition at 8 (Nov. 10, 2004) (SIP provision prohibited emissions that would cause injury or unreasonably interfere with enjoyment of life or use of property).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>43</SU>
                             
                            <E T="03">See, e.g., In the Matter of Oxbow Calcining LLC,</E>
                             Order on Petition No. VI-2020-11 at 10-12 (June 14, 2022) (addressing a situation where a state permitting authority took enforcement action against a source that allegedly caused a violation of a NAAQS, on the basis that this alleged violation also violated permit terms reflecting a general SIP provision prohibiting air pollution).
                        </P>
                    </FTNT>
                    <P>
                        Although uncommon, some SIP provisions expressly identify title V permits as a vehicle for establishing or modifying SIP-based limits. For example, some SIP provisions based on the EPA's Plantwide Applicability Limit (PAL) rules expressly identify title V renewal permits as a potential vehicle for adjusting a PAL.
                        <SU>44</SU>
                        <FTREF/>
                         Where the title V process is specifically identified in a SIP as a means of establishing or defining an applicable requirement of the SIP, questions related to these requirements maybe properly raised during the title V permitting process.
                    </P>
                    <FTNT>
                        <P>
                            <SU>44</SU>
                             
                            <E T="03">See, e.g.,</E>
                             51.166(w)(10)(v); 
                            <E T="03">ExxonMobil Baytown Chemical Order</E>
                             9 at 13-14.
                        </P>
                    </FTNT>
                    <PRTPAGE P="1160"/>
                    <HD SOURCE="HD1">IV. Interface Between NSR and Title V Permitting</HD>
                    <P>
                        Since the title V program was created in the early 1990s, the EPA, state permitting authorities, and other interested stakeholders have grappled with questions related to the intersection of the title I (NSR) 
                        <SU>45</SU>
                        <FTREF/>
                         preconstruction permitting programs and the title V operating permit program. Among other issues, one has persisted: in what situations, and to what extent, should the unique title V oversight tools (
                        <E T="03">e.g.,</E>
                         the EPA's objection authority and the public petition opportunity) be used to address alleged deficiencies related to title I permitting decisions? This issue implicates various questions about the relationship between title V permits and applicable requirements established in other CAA programs. For example, when is an applicable requirement considered established, such that it should be incorporated into a title V permit without further substantive review? Should applicable requirements established under NSR permitting programs be treated the same as applicable requirements established under other CAA programs? The EPA's answer to these questions has changed over time, and two federal circuit courts have reached differing conclusions on the matter, as discussed in section IV.A.3. of this preamble.
                    </P>
                    <FTNT>
                        <P>
                            <SU>45</SU>
                             For purposes of this preamble, the terms “title I permit” and “NSR permit” are used interchangeably to describe a preconstruction permit issued to satisfy the NSR-related requirements of title I of the Clean Air Act.
                        </P>
                    </FTNT>
                    <P>
                        This action proposes to codify the reasonable approach that the EPA has implemented on a case-by-case basis since 2017, as further described and justified in sections IV.A.3., IV.B., and IV.E. of this preamble. In short, provided a source obtains an NSR permit under EPA-approved (or EPA-promulgated) title I rules, with public notice and the opportunity for comment and judicial review, that NSR permit establishes and defines the relevant NSR-related applicable requirements of the SIP (or FIP) for purposes of title V. As with applicable requirements established under other CAA authorities (
                        <E T="03">e.g.,</E>
                         NSPS, NESHAP), the EPA would 
                        <E T="03">not</E>
                         revisit those NSR decisions through the title V process.
                    </P>
                    <P>
                        This approach creates an incentive for permitting authorities to provide opportunities for meaningful public involvement through the most appropriate venue—the NSR permitting process. However, to the extent that the public is deprived of the opportunity to participate in the NSR permitting process, the title V process will serve as a backstop to ensure that each title V permit contains all applicable requirements. In other words, even under the EPA's current (and proposed) framework, there are certain situations in which the EPA 
                        <E T="03">would</E>
                         review substantive NSR issues through the title V permitting process, as explained in more detail in section IV.B.5. of this preamble.
                    </P>
                    <P>The EPA is also soliciting comment on alternative approaches, presented in section IV.F. of this preamble, that would involve using title V to review NSR decisions in more situations.</P>
                    <P>The proposed regulatory changes related to NSR permitting are distinct and severable from the proposed change related to the general duty clause under CAA section 112(r)(1), discussed in section V. of this preamble.</P>
                    <HD SOURCE="HD2">A. Background: Historical and Current EPA Positions</HD>
                    <HD SOURCE="HD3">1. NSR Programs (1977-Present)</HD>
                    <P>The title I (NSR) preconstruction permitting program was established before the title V operating permits program. The NSR program is based on the 1977 Amendments to the CAA. The overall NSR program is comprised of three sub-programs, as discussed later.</P>
                    <P>
                        The NSR program was designed to protect public health and welfare from the effects of air pollution and to preserve and/or improve air quality throughout the nation. 
                        <E T="03">See</E>
                         42 U.S.C. 7470(1), (2), (4). The NSR program requires certain stationary sources of air pollution to obtain air pollution permits prior to beginning construction. Construction of new sources and the modification of certain sources with emissions above statutory and/or regulatory thresholds are subject to “major source” NSR requirements. New sources and modifications below the relevant emissions thresholds may be subject to minor NSR requirements or excluded from NSR altogether.
                    </P>
                    <P>The major NSR program includes two distinct programs that each have unique requirements for new or modified sources. The applicability of these two programs depends on whether the area where the source is located is exceeding the NAAQS for one or more pollutants. The PSD program, based on requirements in part C of title I of the CAA, applies to pollutants for which the area is not exceeding the NAAQS (areas designated as attainment or unclassifiable) and to regulated NSR pollutants for which there are no NAAQS. 42 U.S.C. 7470-7479. The Nonattainment NSR (NNSR) program, based on part D of title I of the CAA, applies to pollutants for which the area is not meeting the NAAQS (areas designated as nonattainment). 42 U.S.C. 7501-7515.</P>
                    <P>To implement the CAA requirements for these programs, most states have EPA-approved SIPs containing PSD and NNSR preconstruction permitting programs that meet the minimum requirements reflected in the EPA's major NSR program regulations at 40 CFR 51.166 and 51.165. Upon EPA approval of a SIP, the state or local air agency becomes the permitting authority for major NSR permits for sources within its boundaries and issues permits under state law. Currently, state and local air agencies issue the vast majority of major NSR permits each year. When a state or local air agency does not have an approved NSR program, federal regulations (40 CFR 52.21, through incorporation into a FIP) apply and either the EPA issues the major NSR permits or a state or local air agency issues the major NSR permits on behalf of the EPA by way of a delegation agreement. For sources located in Indian Country, 18 U.S.C. 1151, the EPA is the permitting authority for major NSR.</P>
                    <P>
                        The permitting program for construction of new and modified non-major sources and minor modifications to major sources is known as the minor NSR program. In addition to the specific major NSR requirements in CAA sections 165 and 173, CAA section 110(a)(2)(C) requires states to develop a program to regulate the construction and modification of any stationary source “as necessary to assure that [NAAQS] are achieved.” 42 U.S.C. 7410(a)(2)(C). The CAA and the EPA's regulations are less prescriptive regarding minimum requirements for minor NSR, so air agencies generally have more flexibility in designing minor NSR programs in their EPA-approved SIPs. 
                        <E T="03">See</E>
                         40 CFR 51.160-51.164. Minor NSR permits are almost exclusively issued by state and local air agencies, although the EPA issues minor NSR permits in many areas of Indian Country. 
                        <E T="03">See</E>
                         40 CFR 49.151-49.165.
                    </P>
                    <P>The applicability of the PSD, NNSR, and/or minor NSR programs to a stationary source must be determined in advance of construction and is a pollutant-specific determination. Thus, a stationary source may be subject to the PSD program for certain pollutants, NNSR for some pollutants, and minor NSR for others.</P>
                    <HD SOURCE="HD3">2. Original Title V Approach to NSR (1990-1997)</HD>
                    <PRTPAGE P="1161"/>
                    <P>
                        As noted previously, the title V program was established in the 1990 CAA Amendments. The legislative history articulates Congress's intent that, notwithstanding the enactment of title V, NSR permits would continue to be issued as they had for over a decade, and that title V permits would be used to incorporate those requirements, but not to alter or impose additional NSR-related requirements.
                        <SU>46</SU>
                        <FTREF/>
                         The text of the CAA implicitly reflects this paradigm. However, the statute does not unambiguously prescribe the details of how EPA should approach the intersection of the NSR and title V permitting programs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>46</SU>
                             See sections IV.E.2. and IV.E.3. of this preamble for further discussion of legislative intent.
                        </P>
                    </FTNT>
                    <P>Thus, when the EPA promulgated the original title V implementing regulations in 1991 and 1992, the agency sought to provide clarity through multiple regulatory provisions, both of which were introduced earlier in this preamble. Again, 40 CFR 70.1(b) states: “All sources subject to these regulations shall have a permit to operate that assures compliance by the source with all applicable requirements. While title V does not impose substantive new requirements, it does require that . . . certain procedural measures be adopted especially with respect to compliance.” Additionally, the EPA created a definition of “applicable requirement” in 40 CFR 70.2 (and later, 71.2) that includes, in relevant part: “all of the following as they apply to emissions units in a part 70 source . . . (1) Any standard or other requirement provided for in the applicable implementation plan approved or promulgated by EPA through rulemaking under title I of the Act that implements the relevant requirements of the Act, including any revisions to that plan promulgated in part 52 of this chapter; (2) Any term or condition of any preconstruction permits issued pursuant to regulations approved or promulgated through rulemaking under title I, including parts C or D, of the Act.”</P>
                    <P>
                        In the preamble of this initial part 70 rulemaking effort, the agency spoke directly to the intersection of title V and title I permitting. The EPA did not express an intention to use the title V permitting process to review the substance of applicable requirements established in preconstruction permitting programs under title I of the CAA. To the contrary, the EPA stated that “[a]ny requirements established during the preconstruction review process also apply to the source for purposes of implementing title V. If the source meets the limits in its NSR permit, the title V operating permit would incorporate these limits 
                        <E T="03">without further review.</E>
                        ” 56 FR 21712, 21738-39 (May 10, 1991) (emphasis added). The EPA stated clearly that “[t]he intent of title V is 
                        <E T="03">not to second-guess</E>
                         the results of 
                        <E T="03">any</E>
                         State NSR program.” 
                        <E T="03">Id.</E>
                         at 21739 (emphasis added). The EPA stated that “[d]ecisions made under the NSR and/or PSD programs (
                        <E T="03">e.g.,</E>
                         Best Available Control Technology [BACT]) 
                        <E T="03">define applicable SIP requirements</E>
                         for the title V source and, if they are not otherwise changed, can be incorporated without further review into the operating permit for the source.” 
                        <E T="03">Id.</E>
                         at 21721 (emphasis added). The preamble to the final rule further confirms that “[d]ecisions made under the NSR and/or PSD programs 
                        <E T="03">define certain applicable SIP requirements</E>
                         for the title V source.” 57 FR 32250, 32259 (July 21, 1992) (emphasis added).
                    </P>
                    <HD SOURCE="HD3">3. Revised Title V Approach to NSR (1997-2017)</HD>
                    <P>Once state permitting authorities began issuing title V permits in the mid-to-late-1990s, the EPA began receiving public petitions challenging those permits. Some of the earliest title V petitions included challenges to various types of NSR permitting decisions, proving a test to the statements the EPA made when promulgating its part 70 rules. The EPA's approach ultimately differed depending on whether the underlying NSR permit was issued under the EPA's federal PSD rules (40 CFR 52.21, administration of which was delegated to many states at the time) or under EPA-approved SIP rules.</P>
                    <P>
                        For NSR permits issued under the federal rules, the EPA's petition responses from 1997 onward followed the agency's interpretations and statements of intent from the early 1990s. In other words, the EPA declined to use the title V petition process to review the merits of NSR permits issued by the EPA or a delegated agency under a FIP. The EPA's reasoning at the time was that appeals of such NSR permits are governed by 40 CFR 124.19 and are heard exclusively by the EPA Environmental Appeals Board (EAB). Thus, the EPA concluded that it need not entertain claims that such permits are deficient when raised in a petition to object to a title V permit.
                        <SU>47</SU>
                        <FTREF/>
                         The EPA consistently reiterated the same or similar statements in the decades that followed.
                        <SU>48</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>47</SU>
                             
                            <E T="03">See In the Matter of Maui Electric Co., Ltd.,</E>
                             Order on Petition (June 16, 1999) 
                            <E T="03">In the Matter of Hawaii Electric Light Co. Ltd.,</E>
                             Order on Petition (Apr. 3, 1998); 
                            <E T="03">In the Matter of Kawaihae Cogeneration,</E>
                             Order on Petition (Mar. 10, 1997) (
                            <E T="03">Kawaihae Order</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>48</SU>
                             
                            <E T="03">See, e.g., In the Matter of East Kentucky Power Cooperative, Inc., Hugh L. Spurlock Generating Station,</E>
                             Order on Petition, 5 n.2 (Aug. 30, 2007) (
                            <E T="03">Spurlock I Order</E>
                            ); 
                            <E T="03">In the Matter of Carmeuse Lime and Stone,</E>
                             Order on Petition No. V-2010-1 at 7 n.1 (Nov. 4, 2011); 
                            <E T="03">see also Hu Honua I Order</E>
                             at 3 n.4.
                        </P>
                    </FTNT>
                    <P>
                        However, starting in 1997, the EPA adopted a different approach to title V permitting with respect to NSR permits issued by state permitting authorities under EPA-approved SIP rules.
                        <SU>49</SU>
                        <FTREF/>
                         The EPA began to interpret section (1) of the definition of “applicable requirement” to allow the EPA, states, and the public to use the title V permitting process to examine the propriety of prior title I permitting decisions. For instance, in the 1997 
                        <E T="03">Shintech I Order,</E>
                         the EPA stated: 
                    </P>
                    <FTNT>
                        <P>
                            <SU>49</SU>
                             For example, within the 
                            <E T="03">1997 Kawaihae Order,</E>
                             in which the EPA declined to review the merits of a PSD permit issued under delegated federal authority, the EPA also announced the following (without explanation): “In contrast, where a state or local government has a SIP-approved PSD program and the [EAB] lacks jurisdiction to entertain PSD permit appeals, the merits of PSD issues are ripe for consideration in a timely veto petition under Title V.” 
                            <E T="03">Kawaihae Order</E>
                             at 3.
                        </P>
                    </FTNT>
                    <EXTRACT>
                        <P>
                            Where a state or local government has a SIP-approved PSD program, the merits of PSD issues can be ripe for consideration in a timely petition to object under Title V. Under 40 CFR 70.1(b), “all sources subject to Title V must have a permit to operate that assures compliance by the source with all applicable requirements.” Applicable requirements are defined in section 70.2 to include “(1) any standard or other requirement provided for in the applicable implementation plan approved or promulgated by EPA through rulemaking under Title I of the [Clean Air] Act . . . .” The [state] defines “federal applicable requirement,” in relevant part, to include “any standard or other requirement provided for in the Louisiana [SIP] approved or promulgated by EPA through rulemaking under title I of the Clean Air Act that implements the relevant requirements of the Clean Air Act, including any revisions to that plan promulgated in 40 CFR part 52, subpart T.” Thus, the applicable requirements of the Shintech Permits include the requirement to obtain a PSD permit 
                            <E T="03">that in turn complies with the applicable PSD requirements under the Act,</E>
                             EPA regulations, and the Louisiana SIP.
                            <SU>50</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>50</SU>
                                 
                                <E T="03">Shintech I Order</E>
                                 at 3 n.2 (emphasis added) (citation omitted).
                            </P>
                        </FTNT>
                    </EXTRACT>
                    <P>
                        In a 1999 letter responding to requests from permitting authorities, the Director of the EPA Office of Air Quality Planning and Standards articulated the agency's then-current understanding of the interaction of title I and title V.
                        <SU>51</SU>
                        <FTREF/>
                         The letter stated that “applicable requirements include the requirement to 
                        <PRTPAGE P="1162"/>
                        obtain preconstruction permits that comply with applicable preconstruction review requirements under the Act, EPA regulations, and SIP's.” The letter expressed the view that section 505(b) of the Act provides a form of corrective action in addition to all the other enforcement authorities the EPA has under the Act. It stated that generally the agency will not object to a title V permit for NSR determinations “made long ago during a prior preconstruction permitting process.” However, regarding recently issued NSR permits, the EPA indicated it may object to improper NSR determinations. Additionally, the letter said that the EPA could object to a title V permit where “EPA believes that an emission unit has not gone through the proper preconstruction permitting process.”
                    </P>
                    <FTNT>
                        <P>
                            <SU>51</SU>
                             Letter from John S. Seitz, U.S. EPA, to Robert Hodanbosi, STAPPA/ALAPCO (May 20, 1999), available at 
                            <E T="03">https://www.epa.gov/sites/production/files/2015-08/documents/hodan7.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        The EPA has also used this reading of the agency's oversight authority under title V as part of the justification for approving state PSD programs.
                        <SU>52</SU>
                        <FTREF/>
                         In these approvals, the EPA pointed to its authority under title I, sections 113 and 167, and stated that title V “has added new tools” for addressing concerns with implementation of PSD requirements by allowing for objection to title V permits under section 505(b) of the Act. However, the authority to revisit an issued preconstruction permit does not appear to have been dispositive to the approval of these PSD programs, as EPA could still conduct oversight using its title I-based authorities.
                    </P>
                    <FTNT>
                        <P>
                            <SU>52</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Approval and Promulgation of Implementation Plans; Oregon, 68 FR 2891, 2899 (Jan. 22, 2003); 
                            <E T="03">see also</E>
                             Approval and Promulgation of Implementation Plans; Idaho; Designation of Areas for Air Quality Planning Purposes; Idaho, 68 FR 2217, 2221 (Jan. 16, 2003).
                        </P>
                    </FTNT>
                    <P>The EPA implicitly or explicitly followed this approach in responding to title V petitions between 1997 and 2017. In general, the petition claims at issue alleged two types of defects related to NSR: First, some claims alleged flaws with the terms of major NSR permits issued by a state permitting authority—for example, that BACT limits in a PSD permit were not stringent enough. The EPA refers to these claims as addressing “NSR permit content.” Second, other claims alleged that a facility should have received a major NSR permit, instead of a minor NSR permit, to authorize the construction of a new source or modification. The EPA refers to these claims as addressing “NSR applicability.” For both types of issues, the EPA indicated that the agency could review whether preconstruction permitting decisions complied with the requirements of the SIP.</P>
                    <P>During this time period, the EPA often limited or qualified its use of title V authorities to address substantive NSR permitting issues. For example, in 1999, the agency stated:</P>
                    <EXTRACT>
                        <P>
                            In determining BACT under a minor NSR program, as in implementing other aspects of SIP preconstruction review programs, a State exercises considerable discretion. Thus, EPA lacks authority to take corrective action merely because the Agency disagrees with a State's lawful exercise of discretion in making BACT-related determinations. State discretion is bounded, however, by the fundamental requirements of administrative law that agency decisions not be arbitrary or capricious, be beyond statutory authority, or fail to comply with applicable procedures.
                            <SU>53</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>53</SU>
                                 
                                <E T="03">In the Matter of Roosevelt Regional Landfill,</E>
                                 Order on Petition, 9 (May 4, 1999).
                            </P>
                        </FTNT>
                    </EXTRACT>
                    <P>
                        Applying this framework, the EPA has also drawn an analogy between this approach and the standard used by the EAB in reviewing EPA-issued PSD permits, described as a “clearly erroneous” standard.
                        <SU>54</SU>
                        <FTREF/>
                         More recently, the agency summarized this framework as follows:
                    </P>
                    <FTNT>
                        <P>
                            <SU>54</SU>
                             
                            <E T="03">See, e.g., Spurlock I Order</E>
                             at 4-5 (Aug. 30, 2007) (“The standard of review applied by the EAB in its review of federal PSD permits has been explained in numerous orders of the EAB. In short, in such appeals, the burden is on a petitioner to demonstrate that review is warranted. Ordinarily, a PSD permit will not be reviewed by the EAB unless the decision of the permitting authority was based on either a clearly erroneous finding of fact or conclusion of law, or involves an important matter of policy or exercise of discretion that warrants review. Thus, when a response to a petition to object to a title V permit requires the Administrator to determine whether an approved state's PSD permitting decision was adequately explained and meets the requirements of its SIP, EPA believes it is appropriate to apply a similar standard of review to that employed by the EAB in its review of federal PSD permits. When EPA promulgated the regulations governing the EAB's exercise of its review authority, the Agency noted that the power of review `should be only sparingly exercised.' Similar deference to the permitting authority is also justified in the case of a PSD permit issued by a state with an approved PSD program, as is the case here.” (quoting 45 FR 33290, 33412 (May 19, 1980); citing 
                            <E T="03">In re Prairie State Generating Company,</E>
                             13 E.A.D. 1 (EAB 2006); 
                            <E T="03">In re Kawaihae Cogeneration,</E>
                             7 E.A.D. 107 (EAB 1997)).
                        </P>
                    </FTNT>
                    <EXTRACT>
                        <P>
                            Where a petitioner's request that the Administrator object to the issuance of a title V permit is based in whole, or in part, on a permitting authority's alleged failure to comply with the requirements of its approved PSD program (as with other allegations of inconsistency with the Act), the burden is on the petitioner to demonstrate to the Administrator that the permitting decision was not in compliance with the requirements of the Act, including the requirements of the SIP. As the EPA has explained in describing its authority to oversee the implementation of the PSD program in states with approved programs, such requirements include that the permitting authority: (1) follow the required procedures in the SIP; (2) make PSD determinations on reasonable grounds properly supported on the record; and (3) describe the determinations in enforceable terms. As the permitting authority for [the state's] SIP-approved PSD program, [the state agency] has substantial discretion in issuing PSD permits. Given this discretion, in reviewing a PSD permitting decision in the title V petition context, the EPA generally will not substitute its own judgment for that of [the state]. Rather, consistent with the decision in 
                            <E T="03">Alaska Dep't of Envt'l Conservation</E>
                             v. 
                            <E T="03">EPA,</E>
                             540 U.S. 461 (2004), in reviewing a petition to object to a title V permit raising concerns regarding a state's PSD permitting decision, the EPA generally will look to see whether the petitioner has shown that the state did not comply with its SIP-approved regulations governing PSD permitting, or whether the state's exercise of discretion under such regulations was unreasonable or arbitrary.
                            <SU>55</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>55</SU>
                                 
                                <E T="03">In the Matter of Appleton Coated, LLC,</E>
                                 Order on Petition Nos. V-2013-12 &amp; V-2013-15 at 5 (Oct. 14, 2016) (
                                <E T="03">Appleton Order</E>
                                ) (citations omitted).
                            </P>
                        </FTNT>
                    </EXTRACT>
                    <P>
                        Between 1997 and 2017, the EPA occasionally articulated further restrictions on the use of title V oversight tools to address title I permitting issues. For example, on at least three occasions, the EPA indicated that “the Agency generally does not object to the issuance of a title V permit due to concerns over BACT or related determinations made long ago during a prior preconstruction permitting process.” 
                        <SU>56</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>56</SU>
                             
                            <E T="03">In the Matter of Georgia Pacific Consumer Products LP Plant,</E>
                             Order on Petition No. V-2011-1 at 17 (July 23, 2012); 
                            <E T="03">Spurlock I Order</E>
                             at 19; 
                            <E T="03">see In the Matter of Chevron Products Company, Richmond, California Facility,</E>
                             Order on Petition No. IX-2004-08 at 9 (Mar. 15, 2005). Note that this statement is based on the EPA policy articulated in the 1999 letter discussed in footnote 51.
                        </P>
                    </FTNT>
                    <P>
                        Additionally, on at least one occasion, the EPA suggested that the title V petition demonstration burden may require a final determination that NSR applies before the EPA can use the title V process to overturn an NSR applicability decision made by the permitting authority. The EPA found “that [the state] has not reached a final determination in this permitting context that PSD is an applicable requirement for these sources, that the USEPA has not determined otherwise, and that a court has not issued a determination in the litigation context. Accordingly, there is no requirement under the facts of this case for the permits to include either PSD limits or a compliance schedule for the source to come into compliance with such limits at this time.” The EPA concluded that “even if [the state] were to recognize that the potential for noncompliance [with title I preconstruction permitting requirements] exists, it is not required to pursue inquiries further in the title V context,” but instead could pursue the 
                        <PRTPAGE P="1163"/>
                        matter through title I enforcement mechanisms.
                        <SU>57</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>57</SU>
                             
                            <E T="03">In the Matter of Midwest Generation-Joliet Generating Station and Will County Generating Stations,</E>
                             Order on Petition No. V-2005-2 at 9-10 (June 14, 2007).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">4. Current Title V Approach to NSR (2017-Present)</HD>
                    <P>Beginning in 2017, the EPA adopted a more nuanced view that, in the EPA's present opinion, better reflects not only the statute and Congress's intent, but also the EPA's regulatory definition of “applicable requirement” and the manner in which the title V permitting program interacts with other types of CAA requirements. As with many of the EPA's views on this topic, the EPA's updated view was articulated within Administrator-signed orders responding to title V petitions on individual title V permits.</P>
                    <P>
                        The first such order was the 2017 
                        <E T="03">PacifiCorp-Hunter I Order.</E>
                        <SU>58</SU>
                        <FTREF/>
                         There, the EPA interpreted the CAA and the EPA's title V regulations to not require permitting authorities (including the EPA) to examine the merits of certain title I permitting decisions in the title V permitting context. Specifically, in response to a petition claiming that a PSD permit (instead of a minor NSR permit) was required for certain changes that occurred at the facility at issue approximately 20 years prior, the EPA explained:
                    </P>
                    <FTNT>
                        <P>
                            <SU>58</SU>
                             
                            <E T="03">In the Matter of PacifiCorp Energy, Hunter Power Plant,</E>
                             Order on Petition No. VIII-2016-4 (Oct. 16, 2017).
                        </P>
                    </FTNT>
                    <EXTRACT>
                        <P>
                            In circumstances such as those present here where a preconstruction permit has been duly obtained, . . . when a permitting authority has made a source-specific permitting decision with respect to a particular construction project under title I, those decisions “define certain applicable SIP requirements for the title V source” for purposes of title V permitting. 57 FR 32250, 32259 (July 21, 1992). The EPA is now interpreting the regulations to mean that the issuance of a[n NSR] permit defines the applicability of preconstruction requirements under section (1) of the definition of “applicable requirement” for the approved construction activities for the purposes of permitting under title V of the Act. . . . These source-specific permitting actions take the general preconstruction permitting requirements of the SIP—the requirement to obtain a particular type of permit and the substantive requirements that must be included in each type of permit—and evaluate at the time of the permitting decision whether and how to apply them to a proposed construction or modification.
                            <SU>59</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>59</SU>
                                 
                                <E T="03">PacifiCorp-Hunter I Order</E>
                                 at 10-11. As the EPA explained: “This interpretation applies to the facts of this Claim, where a permitting authority issued a source-specific title I preconstruction permit subject to public notice and comment and for which judicial review was available.” 
                                <E T="03">Id.</E>
                                 at 11 n.21.
                            </P>
                        </FTNT>
                    </EXTRACT>
                    <FP>Further, the EPA stated:</FP>
                    <EXTRACT>
                        <P>
                            Consistent with this reading, permitting agencies and the EPA need not reevaluate—in the context of title V permitting, oversight, or petition responses—previously issued final preconstruction permits, especially those that have already been subject to public notice and comment and an opportunity for judicial review. Concerns with these final preconstruction permits should instead be handled under the authorities found in title I of the Act. Where a final preconstruction permit has been issued, whether it is a major or minor NSR permit, the terms and conditions of that permit should be incorporated as “applicable requirements” and the permitting authority and the EPA should limit its review to whether the title V permit has accurately incorporated those terms and conditions and whether the title V permit includes adequate monitoring, recordkeeping, and reporting requirements to assure compliance with the terms and conditions of the preconstruction permit.
                            <SU>60</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>60</SU>
                                 
                                <E T="03">PacifiCorp-Hunter I Order</E>
                                 at 19 (citing 42 U.S.C. 7661c(a); 40 CFR 70.6(a)(3), 70.6(c)(1)).
                            </P>
                        </FTNT>
                    </EXTRACT>
                    <P>
                        Shortly after issuing the 
                        <E T="03">PacifiCorp-Hunter I Order,</E>
                         the EPA issued the 
                        <E T="03">Big River Steel Order,</E>
                        <SU>61</SU>
                        <FTREF/>
                         which applied similar statutory and regulatory interpretations to a different set of facts. In 
                        <E T="03">Big River Steel,</E>
                         the EPA declined to use the title V petition process to review whether a PSD permit satisfied the relevant SIP requirements governing PSD permit content (including BACT) and modeling related to the NAAQS. The EPA did so notwithstanding the fact that the PSD permit at issue, and the title V permit being petitioned, were issued at the same time and in the same physical permit document. The EPA's rationale was fully expressed within the 
                        <E T="03">PacifiCorp-Hunter I</E>
                         and 
                        <E T="03">Big River Steel Orders.</E>
                         To the extent those or similar rationales are relevant to this proposed rulemaking, they are presented in section IV.E. of this preamble.
                    </P>
                    <FTNT>
                        <P>
                            <SU>61</SU>
                             
                            <E T="03">In the Matter of Big River Steel, LLC,</E>
                             Order on Petition No. VI-2013-10 (Oct. 31, 2017).
                        </P>
                    </FTNT>
                    <P>
                        Since the 2017 
                        <E T="03">PacifiCorp-Hunter I</E>
                         and 
                        <E T="03">Big River Steel Orders,</E>
                         the EPA has issued approximately 20 other title V petition orders addressing similar issues under different fact patterns. Although the EPA has consistently followed the overarching interpretations and policies articulated in the 
                        <E T="03">PacifiCorp-Hunter I</E>
                         and 
                        <E T="03">Big River Steel Orders,</E>
                         each decision about 
                        <E T="03">whether</E>
                         those interpretations were applicable depended on the specific facts at issue.
                        <SU>62</SU>
                        <FTREF/>
                         Through these case-by-case decisions, the EPA has clarified various aspects of the EPA's interpretation of the title V provisions. However, because those decisions are spread across many different orders, the EPA understands that not all stakeholders—including permitting authorities, permittees, and members of the public—may fully understand the EPA's views about which types of issues are, or are not, subject to review through title V.
                        <SU>63</SU>
                        <FTREF/>
                         This preamble summarizes the most relevant aspects of these prior decisions in order to provide additional clarity about the EPA's current views.
                    </P>
                    <FTNT>
                        <P>
                            <SU>62</SU>
                             
                            <E T="03">See, e.g., PacifiCorp-Hunter I Order</E>
                             at 11 n.21 (“This interpretation applies to the facts of this Claim, where a permitting authority issued a source-specific title I preconstruction permit subject to public notice and comment and for which judicial review was available. The EPA is not considering at this time whether other circumstances may warrant a different approach.”); 
                            <E T="03">Sierra Club</E>
                             v. 
                            <E T="03">EPA,</E>
                             926 F.3d 844, 850 (D.C. Cir. 2019) (emphasizing the case-specific nature the EPA's decision to apply the interpretation at issue in 
                            <E T="03">PacifiCorp-Hunter I,</E>
                             as well as the case-specific nature of any future EPA decisions to apply or not apply the same interpretation to different fact patterns).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>63</SU>
                             In recent permitting decisions and title V petitions, the EPA has observed that both state permitting authorities and public petitioners have often misapplied, misinterpreted, or ignored the interpretations and policies expressed in these orders.
                        </P>
                    </FTNT>
                    <P>
                        In some of these decisions, the EPA concluded that NSR permitting actions established the relevant “applicable requirements” for title V purposes, and the EPA declined to review the substance of those applicable requirements in the title V petition context. The EPA applied this approach to many different types of issues, including the sufficiency of major NSR permit terms,
                        <SU>64</SU>
                        <FTREF/>
                         the sufficiency of minor NSR permit terms,
                        <SU>65</SU>
                        <FTREF/>
                         issues related to modeling and the NAAQS,
                        <SU>66</SU>
                        <FTREF/>
                         procedures used to issue NSR permits,
                        <SU>67</SU>
                        <FTREF/>
                         whether major NSR is applicable,
                        <SU>68</SU>
                        <FTREF/>
                         and other 
                        <PRTPAGE P="1164"/>
                        NSR-related issues.
                        <SU>69</SU>
                        <FTREF/>
                         Some of these orders involved situations where NSR permits were issued well before the title V permits being challenged,
                        <SU>70</SU>
                        <FTREF/>
                         while others involved more contemporaneous NSR and title V permitting decisions.
                        <SU>71</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>64</SU>
                             
                            <E T="03">AK Steel Order</E>
                             at 9-13; 
                            <E T="03">In the Matter of Riverview Energy Corp.,</E>
                             Order on Petition No. V-2019-10 at 19-29 (Mar. 26, 2020) (
                            <E T="03">Riverview Order</E>
                            ); 
                            <E T="03">In the Matter of South Louisiana Methanol, LP, St. James Methanol Plant,</E>
                             Order on Petition Nos. VI-2016-24 &amp; VI-2017-014 at 8-10 (May 29, 2018) (
                            <E T="03">South Louisiana Methanol Order</E>
                            ); 
                            <E T="03">Big River Steel Order</E>
                             at 8-20.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>65</SU>
                             
                            <E T="03">In the Matter of Delaware City Refining Company, LLC, Delaware City Refinery,</E>
                             Order on Petition No. III-2022-10 at 26 (July 5, 2023) (
                            <E T="03">Delaware City Refinery Order</E>
                            ); 
                            <E T="03">In the Matter of Valero Refining-Texas, L.P., Valero Houston Refinery,</E>
                             Order on Petition No. VI-2021-8 at 65-66 (June 30, 2022) (
                            <E T="03">Valero Houston Order</E>
                            ); 
                            <E T="03">In the Matters of Superior Silica Sands &amp; Wisconsin Proppants, LLC,</E>
                             Order on Petition Nos. V-2016-18 &amp; V-2017-2 at 14-15 (Feb. 26, 2018) (
                            <E T="03">SSS/WP Order</E>
                            ); 
                            <E T="03">In the Matter of Tennessee Valley Authority, Gallatin Fossil Plant,</E>
                             Order on Petition Nos. IV-2016-11 &amp; IV-2017-17 at 19-20 (January 30, 2018) (
                            <E T="03">TVA Gallatin II Order</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>66</SU>
                             
                            <E T="03">Riverview Order</E>
                             at 19-21; 
                            <E T="03">Big River Steel Order</E>
                             at 8-20.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>67</SU>
                             
                            <E T="03">AK Steel Order</E>
                             at 9-13.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>68</SU>
                             
                            <E T="03">In the Matter of Waelz Sustainable Products, LLC,</E>
                             Order on Petition No. V-2021-10 at 9-16 (Mar. 14, 2023) (
                            <E T="03">Waelz Order</E>
                            ); 
                            <E T="03">In the Matter of Yuhuang Chemical Inc. Methanol Plant,</E>
                             Order on Petition Nos. VI-2017-5 &amp; VI-2017-13 at 7-8 (Apr. 2, 2018) (
                            <E T="03">Yuhuang II Order</E>
                            ); 
                            <E T="03">In the Matter of ExxonMobil Corp., Baytown Olefins Plant,</E>
                             Order on Petition No. 
                            <PRTPAGE/>
                            VI-2016-12 at 9-12 (
                            <E T="03">ExxonMobil Baytown Olefins Order</E>
                            ); 
                            <E T="03">PacifiCorp-Hunter I Order</E>
                             at 8-20.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>69</SU>
                             
                            <E T="03">In the Matter of ExxonMobil Corp., Baytown Refinery,</E>
                             Order on Petition No. VI-2016-14 at 12-13 (
                            <E T="03">ExxonMobil Baytown Refinery Order</E>
                            ); 
                            <E T="03">ExxonMobil Baytown Olefins Order</E>
                             at 9-12 .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>70</SU>
                             
                            <E T="03">Delaware City Refinery Order</E>
                             at 16; 
                            <E T="03">Valero Houston Order</E>
                             at 65-66; 
                            <E T="03">ExxonMobil Baytown Refinery Order</E>
                             at 12-13, 
                            <E T="03">ExxonMobil Baytown Olefins Order</E>
                             at 9-12; 
                            <E T="03">TVA Gallatin II Order</E>
                             at 19-20.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>71</SU>
                             
                            <E T="03">Waelz Order</E>
                             at 13-15; 
                            <E T="03">Riverview Order</E>
                             at 24-28; 
                            <E T="03">South Louisiana Methanol Order</E>
                             at 9; 
                            <E T="03">Yuhuang II Order</E>
                             at 7-8; 
                            <E T="03">SSS/WP Order</E>
                             at 14-15; 
                            <E T="03">Big River Steel Order</E>
                             at 8-20.
                        </P>
                    </FTNT>
                    <P>
                        In other orders with materially different factual underpinnings, the EPA determined that it 
                        <E T="03">would</E>
                         be appropriate to review certain NSR-related issues through the title V permitting process. For example, the EPA substantively engaged with title V petition claims concerning the sufficiency of monitoring established in NSR permits,
                        <SU>72</SU>
                        <FTREF/>
                         requirements involving an explicit overlap between NSR and title V,
                        <SU>73</SU>
                        <FTREF/>
                         and other NSR issues where no underlying NSR permit was issued 
                        <SU>74</SU>
                        <FTREF/>
                         or where the underlying NSR permit did not involve public notice and the opportunity for comment.
                        <SU>75</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>72</SU>
                             
                            <E T="03">In the Matter of Gulf Coast Growth Ventures, LLC, Olefins, Derivative, &amp; Utilities Plant,</E>
                             Order on Petition No. VI-2021-3 at 17-19 (May 12, 2022) (
                            <E T="03">Gulf Coast Growth Ventures Order</E>
                            ); 
                            <E T="03">ExxonMobil Baytown Chemical Order</E>
                             at 20-21; 
                            <E T="03">South Louisiana Methanol Order</E>
                             at 10-11; 
                            <E T="03">Yuhuang II Order</E>
                             at 8; 
                            <E T="03">see also, e.g., Big River Steel Order</E>
                             at 17, 17 n.30, 19 n.32, 20; 
                            <E T="03">PacifiCorp-Hunter I Order</E>
                             at 16, 17, 18, 18 n.33, 19.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>73</SU>
                             
                            <E T="03">Suncor East Order</E>
                             at 53-54; 
                            <E T="03">ExxonMobil Baytown Chemical Order</E>
                             at 13-14; 
                            <E T="03">In the Matter of Coyote Station Power Plant,</E>
                             Order on Petition Nos. VIII-2019-1 &amp; VIII-2020-8 at 12-13 (January 15, 202) (
                            <E T="03">Coyote Station Order</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>74</SU>
                             
                            <E T="03">Suncor East Order</E>
                             at 45-48, 54-55; 
                            <E T="03">SRP Agua Fria Order</E>
                             at 11 n.18; 
                            <E T="03">In the Matter of Salt River Project Agricultural Improvement &amp; Power District, Desert Basin Generating Station,</E>
                             Order on Petition No. IX-2022-3 at 12 n.20 (July 28, 2022) (
                            <E T="03">SRP Desert Basin Order</E>
                            ); 
                            <E T="03">In the Matter of BP Products North America, Inc., Whiting Business Unit,</E>
                             Order on Petition No. V-2021-9 at 13 n.24 (Mar. 4, 2022) (
                            <E T="03">BP Whiting II Order</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>75</SU>
                             
                            <E T="03">Suncor East Order</E>
                             at 48; 
                            <E T="03">Coyote Station Order</E>
                             at 12.
                        </P>
                    </FTNT>
                    <P>
                        Two of the EPA's petition orders—the 
                        <E T="03">PacifiCorp Hunter I Order</E>
                         and the 
                        <E T="03">ExxonMobil Baytown Olefins Order</E>
                        —were challenged in different federal circuit courts. The U.S. Court of Appeals for the Fifth Circuit issued the first ruling, upholding the 
                        <E T="03">ExxonMobil Baytown Olefins Order. Env't Integrity Project</E>
                         v. 
                        <E T="03">EPA,</E>
                         969 F.3d 529 (5th Cir. 2020). There, the court found persuasive the “EPA's view that Title V permitting is not the appropriate vehicle for reexamining the substantive validity of underlying Title I preconstruction permits.” 
                        <E T="03">Id.</E>
                         at 253. The court's conclusion was “based principally on Title V's text, Title V's structure and purpose, and the structure of the Act as a whole.” 
                        <E T="03">Id.</E>
                         at 249.
                        <SU>76</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>76</SU>
                             The court stated its conclusion several ways, as the following examples illustrate: “Concluding EPA's interpretation of the Title V program is independently persuasive and therefore entitled to the mild form of deference recognized by 
                            <E T="03">Skidmore</E>
                             v. 
                            <E T="03">Swift &amp; Co.,</E>
                             323 U.S. 134 (1944), we deny the petition.” 969 F.3d at 242. “[W]e find [the EPA's] reasoning persuasive as a construction of the relevant provisions of Title V and its implementing regulations.” 
                            <E T="03">Id.</E>
                             at 247. “Applying 
                            <E T="03">Skidmore,</E>
                             we ask whether EPA's interpretation of Title V and its implementing regulations in the 
                            <E T="03">Hunter</E>
                             Order is persuasive. Specifically, we inquire into the persuasiveness of EPA's current view that the Title V permitting process does not require substantive reevaluation of the underlying Title I preconstruction permits applicable to a pollution source. As we read it, the 
                            <E T="03">Hunter</E>
                             Order defends the agency's interpretation based principally on Title V's text, Title V's structure and purpose, and the structure of the Act as a whole. Having examined these reasons and found them persuasive, we conclude that EPA's current approach to Title V merits 
                            <E T="03">Skidmore</E>
                             deference.” 
                            <E T="03">Id.</E>
                             at 249.
                        </P>
                    </FTNT>
                    <P>
                        Shortly thereafter, the U.S. Court of Appeals for the Tenth Circuit issued a ruling vacating and remanding the 
                        <E T="03">PacifiCorp-Hunter I Order. Sierra Club</E>
                         v. 
                        <E T="03">EPA,</E>
                         964 F.3d 882 (10th Cir. 2020). Unlike the Fifth Circuit, the Tenth Circuit did not address the EPA's statutory interpretation but instead rejected the EPA's reasoning as inconsistent with the EPA's regulations. 
                        <E T="03">Id.</E>
                         at 897. According to the Tenth Circuit, the EPA's regulations require that title V permits ensure compliance with all “applicable requirements,” which the court interpreted to include all requirements in the SIP, including those related to major NSR. 
                        <E T="03">Id.</E>
                         at 885-86, 890-91.
                    </P>
                    <P>Because these two courts ruled on different grounds (with the Fifth Circuit focusing on the statute, and the Tenth Circuit focusing on the EPA's existing regulations), the legal reasoning underlying their holdings is not in direct conflict. However, for practical purposes, the differing rulings have made it difficult for the EPA to apply a uniform interpretation of its current title V regulations nationwide.</P>
                    <P>
                        Within the Tenth Circuit's jurisdiction, in the EPA's subsequent responses to petitions on the PacifiCorp-Hunter permit (
                        <E T="03">PacifiCorp-Hunter II</E>
                         
                        <E T="51">77</E>
                        <FTREF/>
                         and 
                        <E T="03">PacifiCorp-Hunter III</E>
                         
                        <SU>78</SU>
                        <FTREF/>
                        ), the EPA reviewed whether a source should have obtained a major NSR permit for projects previously authorized by a minor NSR permit. This review was based on the Tenth Circuit's decision on the 
                        <E T="03">PacifiCorp-Hunter I Order.</E>
                    </P>
                    <FTNT>
                        <P>
                            <SU>77</SU>
                             
                            <E T="03">In the Matter of PacifiCorp Energy, Hunter Power Plant,</E>
                             Order on Petition Nos. VIII-2016-4 &amp; VIII-2020-10 (Jan. 13, 2021).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>78</SU>
                             
                            <E T="03">In the Matter of PacifiCorp Energy, Hunter Power Plant,</E>
                             Order on Petition No. VIII-2022-2 (Sept. 27, 2022).
                        </P>
                    </FTNT>
                    <P>In title V petition orders regarding permits issued by states outside of the Tenth Circuit, however, the EPA has followed a different approach. As the EPA has explained:</P>
                    <EXTRACT>
                        <P>
                            EPA continues to believe that the interpretation of the CAA upheld by the Fifth Circuit's decision in 
                            <E T="03">Environmental Integrity Project</E>
                             v. 
                            <E T="03">EPA,</E>
                             969 F.3d 529 (5th Cir. 2020), is correct. EPA thus intends, where supported by the facts of individual permits, to continue to apply the reasoning of 
                            <E T="03">In re Big River Steel, LLC,</E>
                             Order on Petition No. VI-2013-10 (October 31, 2017), when issuing and reviewing title V permits and reviewing petitions on permits for sources in states outside of the Tenth Circuit. That is, where EPA has approved a state's title I permitting program, duly issued preconstruction permits establish the NSR-related “applicable requirements” for the purposes of title V. As with “applicable requirements” established through other CAA authorities, the terms and conditions of those permits should be incorporated into a source's title V permit without a further round of substantive review as part of the title V process.
                            <SU>79</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>79</SU>
                                 
                                <E T="03">PacifiCorp-Hunter III Order</E>
                                 at 16 n.29; 
                                <E T="03">see also PacifiCorp-Hunter II Order</E>
                                 at 15 n.26.
                            </P>
                        </FTNT>
                    </EXTRACT>
                    <P>
                        Thus, when reviewing permits issued by permitting authorities in states beyond the Tenth Circuit's jurisdiction, the EPA has continued to apply its approach dating back to 2017 and has, in many instances, declined to use the title V process to review the substance of NSR permitting decisions. In the situations outside the Tenth Circuit where the EPA decided that it 
                        <E T="03">was</E>
                         appropriate to use the title V process to review certain NSR issues, these decisions were 
                        <E T="03">not</E>
                         based on the Tenth Circuit's interpretation of the EPA's regulations, but rather on factual distinctions that, in the EPA's view, provided a basis for reviewing such issues under EPA's post-2017 interpretation of the regulations.
                        <SU>80</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>80</SU>
                             
                            <E T="03">See Suncor East Order</E>
                             at 46 n.61; 
                            <E T="03">Gulf Coast Growth Ventures Order</E>
                             at 17 n.28; 
                            <E T="03">ExxonMobil Baytown Chemical Order</E>
                             at 14 n.27; 
                            <E T="03">BP Whiting II Order</E>
                             at 13 n.24; 
                            <E T="03">Coyote Station Order</E>
                             at 12.
                        </P>
                    </FTNT>
                    <P>
                        As explained in the next section of this preamble, the EPA continues to maintain that the 
                        <E T="03">Big River Steel Order</E>
                         and subsequent title V orders reflect the best interpretation not only of the relevant statutory provisions, but also of the existing regulations. Nonetheless, in light of the differing circuit court decisions, the EPA considers it prudent to update the EPA's regulations to reflect its interpretation of the statute. The changes proposed in this rulemaking will allow the EPA to apply a single framework across the nation by amending the text in the regulations. 
                        <PRTPAGE P="1165"/>
                        This action thus addresses the ruling from the Tenth Circuit by amending the regulatory language that it found to be in conflict with the EPA's current interpretation. It also more clearly aligns the EPA's regulations with the EPA's statutory interpretation endorsed by the Fifth Circuit.
                    </P>
                    <HD SOURCE="HD2">B. Proposed Action</HD>
                    <P>
                        The EPA proposes to update its regulations to more closely reflect the agency's current view regarding the intersection between title I permitting and title V permitting. In sum: provided a source obtains an NSR permit under EPA-approved (or EPA-promulgated) title I rules, with public notice and the opportunity for comment and judicial review, such NSR permit establishes the NSR-related “applicable requirements” of the SIP (or FIP) for purposes of title V. As with “applicable requirements” established under other CAA authorities (
                        <E T="03">e.g.,</E>
                         NSPS, NESHAP), the EPA would 
                        <E T="03">not</E>
                         revisit those NSR decisions through the title V process.
                    </P>
                    <P>
                        The following subsections of this preamble explore the situations in which NSR-related applicable requirements of the SIP (or FIP) would effectively be established through the NSR process, as well as situations in which the title V process could be used to further address or define those requirements. Determining the extent to which title V should be used to address NSR-related requirements inherently requires a fact-specific, case-by-case analysis of multiple variables associated with both title I and title V permitting. However, in general, the EPA's framework applies similarly regardless of: (i) the stage of the title V permitting or oversight process at issue; (ii) the NSR permit's origin (
                        <E T="03">i.e.,</E>
                         from a SIP or a FIP), (iii) the type of substantive NSR requirement at issue (
                        <E T="03">e.g.,</E>
                         NSR permit terms or major NSR applicability); and (iv) the procedures by which the NSR permit is incorporated into the title V permit (
                        <E T="03">e.g.,</E>
                         sequentially or concurrently issued permits).
                    </P>
                    <HD SOURCE="HD3">1. Different Stages of the Title V Permitting and Oversight Process</HD>
                    <P>The EPA's views regarding the NSR-title V interface have primarily been discussed in the context of one specific oversight tool: the EPA's responses to title V petitions. This rulemaking would further codify the scope of issues that would be within, or beyond, the scope of the EPA's review in responding to title V petitions. However, the concepts underlying the EPA's current view—as well as this proposed rule—are not confined to title V petitions, but extend to other aspects of title V permitting. Specifically, the EPA's approach is equally relevant: (i) when prospective permittees prepare title V permit applications; (ii) when permitting authorities (including EPA, where applicable) develop title V permits and respond to public comments on draft title V permits, (iii) when EPA reviews and decides whether to object to proposed title V permits during its 45-day review period; (iv) when EPA considers reopening title V permits for cause; and (v) when EPA considers other programmatic oversight actions under, for example, 40 CFR 70.10.</P>
                    <HD SOURCE="HD3">2. Different Origins of NSR Permits</HD>
                    <P>As described earlier in this preamble, the EPA's approach to reviewing NSR issues through title V diverged in the late-1990s, depending on whether the underlying NSR permit was issued under a state's EPA-approved SIP rules (which the EPA would review) or EPA-promulgated FIP rules (which the EPA would not review). At the time, this distinction was based on the differing routes to review such NSR permitting actions; appeals of SIP-based NSR permits were reviewed through the state court system, while appeals of FIP-based NSR permits proceeded through the EAB and federal court system.</P>
                    <P>
                        Instead of presenting a basis to treat SIP-based and FIP-based title I permits differently, these NSR permit appeal pathways highlight why they should be treated similarly. Both SIP-based and FIP-based appeal pathways promote public involvement and ensure the substantive validity of the underlying NSR permitting decisions. Both pathways are similar to those used to establish (and, if necessary, challenge) other types of applicable requirements of the CAA. See section IV.E.4.a. of this preamble for additional information. The fact that one pathway leads to the state courts, and the other pathway leads to the federal courts, simply reflects the cooperative federalism system established by Congress for the NSR program.
                        <SU>81</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>81</SU>
                             For additional information about how the EPA's approach to SIP-based NSR permits comports with the structure of the CAA and congressional intent, see sections IV.E.2. and IV.E.3. of this preamble.
                        </P>
                    </FTNT>
                    <P>
                        Overall, the EPA does not view the difference between NSR-based requirements established pursuant to a SIP, or NSR-based requirements established pursuant a FIP, to be meaningful insofar as title V is concerned. Both processes effectively establish and define the NSR-related requirements of title I for title V purposes. Accordingly, the EPA's proposed rule would codify the EPA's current approach, which does not differentiate between NSR permits issued pursuant to a SIP or a FIP.
                        <SU>82</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>82</SU>
                             This is consistent with the existing regulatory definition of “applicable requirement,” which treats SIP-based and FIP-based requirements the same. 
                            <E T="03">See</E>
                             40 CFR 70.2, 71.2 (definition of applicable requirement, items (1) and (2)).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">3. Different Types of NSR Requirements</HD>
                    <P>
                        The EPA's current (and proposed) approach applies regardless of the types of NSR requirements involved. That is, once an NSR permit has been issued under EPA-approved (or EPA-promulgated) title I rules, with public notice and the opportunity for comment and judicial review, that NSR permit defines the NSR-related requirements of the SIP (or FIP) that are applicable to the construction of the new source or modification that was the subject of the permit. The terms of both major and minor NSR permits are applicable requirements that must be included in title V permits.
                        <SU>83</SU>
                        <FTREF/>
                         These permit conditions are not derived or created within or through the title V process. Thus, the title V permitting process should not be used to reevaluate the terms of such major NSR or minor NSR permits, including questions about (i) the content of the NSR permit (
                        <E T="03">e.g.,</E>
                         whether the permit limits reflect BACT), (ii) whether additional requirements (
                        <E T="03">e.g.,</E>
                         major NSR requirements) should have been applicable to the construction, and (iii) other types of NSR requirements (
                        <E T="03">e.g.,</E>
                         whether the permitting authority correctly determined that the construction would not cause or contribute to a violation of the NAAQS).
                    </P>
                    <FTNT>
                        <P>
                            <SU>83</SU>
                             The EPA's existing regulations reflect this fact. The current definition of “applicable requirement” includes “
                            <E T="03">Any</E>
                             term or condition of 
                            <E T="03">any</E>
                             preconstruction permits issued pursuant to regulations approved or promulgated through rulemaking under title I, including Parts C or D, of the Act.” 40 CFR 70.2 (emphasis added). This definition includes not only the specifically listed major NSR permits (required under parts C or D), but also minor NSR permits issued under a SIP. This language, included in the 1992 final rule, reflects a change from the language in the 1991 proposed rule, which only included major NSR permits. 
                            <E T="03">See</E>
                             57 FR at 32276; 56 FR at 21768. Nonetheless, in order to provide maximum clarity to the public, the EPA proposes a small change to make the inclusion of minor NSR permit requirements more explicit. Note that not every single term of every single NSR permit is an “applicable requirement” that must be included in a title V permit. Some terms of NSR permits may no longer be applicable because, for example, they are obsolete or extraneous. 
                            <E T="03">See White Paper for Streamlined Development of Part 70 Permit Applications,</E>
                             7-16 (July 10, 1995).
                        </P>
                    </FTNT>
                    <P>
                        This principle is perhaps most intuitive with respect to permit content. When a permitting authority authorizes construction by issuing either a major NSR permit or minor NSR permit, it establishes emission limits and other 
                        <PRTPAGE P="1166"/>
                        standards necessary to satisfy the SIP requirements relevant to either major or minor NSR. For example, PSD permits must include emission limits reflecting BACT; NNSR permits must include emission limits reflecting the Lowest Achievable Emissions Rate (LAER), and minor NSR permits may contain analogous requirements depending on the terms of the SIP. Although SIPs contain general criteria for establishing those limits, individual permit actions are necessary to specifically define the limits for each source subject to NSR. Once these limitations are established through the NSR permitting process, the title V process should not be used to re-evaluate whether the resulting limits reflect the general SIP requirements related to BACT, LAER, or other similar requirements.
                    </P>
                    <P>
                        Similar concepts apply to questions about NSR applicability. SIPs contain general criteria and thresholds for determining the applicability of different SIP requirements. However, determining which specific requirements apply to individual emission units requires a fact-specific permitting exercise. When a permitting authority authorizes construction by issuing either a minor NSR permit or major NSR permit, it decides which NSR-related SIP requirements are applicable to different aspects of the project on a pollutant-by-pollutant basis. The resulting NSR permit might include PSD requirements (
                        <E T="03">e.g.,</E>
                         BACT) for some pollutants, NNSR requirements (
                        <E T="03">e.g.,</E>
                         LAER) for other pollutants, and/or minor NSR requirements for yet other pollutants. In this manner, within a single NSR permit action, questions about the applicability of different NSR requirements may be inextricably linked with questions about the content of the NSR permit. Further, questions about NSR permit content and NSR applicability are fundamentally similar because both questions seek to answer whether permit limits are set at a level stringent enough to satisfy the relevant general SIP requirements, and both questions require a highly technical application of general SIP criteria to specific circumstances at the source.
                        <SU>84</SU>
                        <FTREF/>
                         Thus, once an NSR permit is issued, the limitations and other terms of that permit establish all relevant NSR-related requirements of the SIP (whether major or minor NSR) that apply to construction or modification of the source, and should be incorporated into the title V permit without further review.
                        <SU>85</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>84</SU>
                             For example, questions about whether (i) an emission limit that purports to satisfy BACT should instead be made more stringent in order to satisfy BACT are similar to questions about whether (ii) an emission limit that purports to satisfy minor NSR requirements should instead be made more stringent in order to satisfy BACT.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>85</SU>
                             See section IV.E.4.a. of this preamble for additional discussion about how the EPA's treatment of NSR applicability issues aligns with the EPA's treatment of other types of CAA applicability issues.
                        </P>
                    </FTNT>
                    <P>
                        Permitting authorities satisfy other types of NSR requirements in a SIP when issuing NSR permits. One requirement that frequently arises in the context of title V petitions involves determining that the new source or modification will not cause or contribute to a violation of the NAAQS. Again, to satisfy this requirement, the state must undertake a fact-specific analysis through the NSR permitting process. This analysis may (but does not always) involve atmospheric dispersion modeling, and this may (but does not always) result in the imposition of additional permit terms that restrict emissions in order to protect the NAAQS.
                        <SU>86</SU>
                        <FTREF/>
                         In all cases, the NSR permitting process is designed to ensure that the NSR permit ultimately contains whatever specific conditions are necessary to satisfy this NSR SIP requirement. Similar principles hold true for a variety of other substantive NSR requirements in SIPs, including a variety of requirements that are unique to NNSR.
                    </P>
                    <FTNT>
                        <P>
                            <SU>86</SU>
                             In this manner, not all NSR-based SIP requirements related to the NAAQS result in the imposition of requirements that apply to emission units at a source. As discussed previously, only those requirements that “apply to emissions units in a part 70 source” qualify as “applicable requirements” for title V purposes. 40 CFR 70.2; 
                            <E T="03">see</E>
                             40 CFR 71.2.
                        </P>
                    </FTNT>
                    <P>
                        Overall, substantive issues concerning NSR permit content, NSR applicability, and other NSR requirements are fundamentally similar. Each of these decisions require a state to derive specific requirements for an individual source from general criteria in the NSR portion of the SIP (
                        <E T="03">e.g.,</E>
                         requirements to include limits reflecting certain technology-based criteria, to issue major NSR permits to projects meeting certain applicability criteria, or to ensure that permits meet certain criteria relevant to the NAAQS). Each of these determinations involve relatively complex, fact-specific decisionmaking, which occurs during the NSR permitting process. Once that process concludes, the state issues an NSR permit that contains these source-specific applicable requirements of the SIP for the construction project being authorized. Thus, under the EPA's current (and proposed) approach, all types of different NSR-related issues are generally treated the same for purposes of title V review. The merit and validity of these substantive requirements are subject to review and correction through the available mechanisms for appeal of the NSR permit, and need not be further reviewed by a state permitting authority or the EPA through title V.
                    </P>
                    <P>
                        Note that compliance with procedural requirements associated with the issuance of NSR permits are also subject to review in appeals of NSR permits and are also not directly reviewable through title V. However, the latter is for reasons not directly related to the interpretation of “applicable requirements” at issue in this proposed rule. Under the statute and the EPA's existing regulations, the EPA can object to a title V permit that does not comply with “applicable requirements” of the CAA (as that term is defined in EPA regulations) or requirements of part 70, including procedural requirements of part 70. 
                        <E T="03">See</E>
                         42 U.S.C. 7661d(b); 40 CFR 70.8(c)(1), 70.12(a)(2), (a)(2)(ii)-(iv). Notably, the EPA's authority to object under CAA section 505(b) only extends to the particular proposed title V permit before the agency for review.
                        <SU>87</SU>
                        <FTREF/>
                         Procedural requirements associated with NSR permit issuance are not “applicable requirements” for title V purposes because they do not “apply to emissions units at a part 70 source.” 40 CFR 70.2. Rather, they dictate the behavior of permitting authorities in issuing NSR permits. Procedural requirements associated with NSR permit issuance are also not part 70 requirements because they are not related to title V or the part 70 regulations governing the issuance of a specific title V permit. Thus, alleged violations of procedural requirements associated with NSR permit issuance generally would not provide an independent basis for the EPA to object to a title V permit that incorporates such an NSR permit.
                        <SU>88</SU>
                        <FTREF/>
                         Nonetheless, although procedural flaws with the issuance of an NSR permit would not provide a direct basis for the EPA to object to a title V permit, such procedural issues could impact whether other more substantive NSR issues should be reviewed through the title V process. See section IV.B.5.a. of this preamble for further information.
                    </P>
                    <FTNT>
                        <P>
                            <SU>87</SU>
                             The references within CAA section 505(b) to “any permit,” “the proposed permit,” “a permit,” “the permit,” etc. apply to the title V permit that a permitting authority proposes to issue and transmits to EPA under CAA section 505(a)(1). 42 U.S.C. 7661d(a), (b)(1), (b)(2); 
                            <E T="03">see also</E>
                             40 CFR 70.8(c)(1), (d) (similar language and cross-references as the statute), 70.12(a)(1) (requirement that petitioners identify the specific title V permit action on which the petition is based), 70.12(a)(2) (petition claims must be based on alleged deficiencies in the “permit process” associated with the title V permit being petitioned).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>88</SU>
                             
                            <E T="03">See Century Aluminum Order</E>
                             at 19-20.
                        </P>
                    </FTNT>
                    <PRTPAGE P="1167"/>
                    <HD SOURCE="HD3">4. Different Procedures for Incorporating NSR Permits Into Title V Permits</HD>
                    <P>
                        In most cases, the EPA's current (and proposed) approach applies in the same way regardless of the procedures by which a state permitting authority incorporates the terms of an NSR permit into a title V permit. In other words, as long as a permitting authority formally issues an identifiable NSR permit that has the force of law 
                        <SU>89</SU>
                        <FTREF/>
                        —and regardless of whether the NSR and title V permits are issued sequentially, contemporaneously, or even in the same physical document—the unique title V oversight tools should not be used to review the NSR-related decisionmaking underlying that NSR permit.
                    </P>
                    <FTNT>
                        <P>
                            <SU>89</SU>
                             Because it is the NSR permit that establishes the “applicable requirements” for title V purposes, the EPA has long explained that title V permits do not supersede title I permits—which must remain in effect to authorize construction and/or operations—even after the terms of a title I permit are incorporated into a title V permit. 
                            <E T="03">See, e.g.,</E>
                             69 FR 10167, 10170 (Mar. 4, 2004); 66 FR 64039, 64040 (Dec. 11, 2001); Letter from John S. Seitz, EPA, to Robert Hodanbosi &amp; Charles Lagges, STAPPA/ALAPCO, Encl. A at 4 (May 20, 1999).
                        </P>
                    </FTNT>
                    <P>
                        The EPA's approach is most straightforward when an NSR permit is issued in final form prior to the initiation of any title V permitting action, or when an NSR permit has already been included in a previous version of a title V permit that is up for renewal. This is the default approach, as the EPA's regulations allow regulated entities subject to major NSR preconstruction permitting requirements to submit a title V permit application within 1 year after beginning operation, in most cases. 40 CFR 70.5(a)(1)(ii); 71.5(a)(1)(ii). Additionally, where new requirements become applicable to a source, including by virtue of a change to the source (
                        <E T="03">e.g.,</E>
                         minor NSR requirements), the timeline for reopening a source's title V permit to include such requirements depends on the amount of time left in the title V permit; required revisions would either need to be completed within 18 months or at the next permit renewal. 40 CFR 70.7(f)(1)(i), 71.1(f)(1)(i). Regardless of the specific timing, it should be straightforward in these instances to simply incorporate the applicable requirements from the previously finalized NSR permit into the title V permit.
                    </P>
                    <P>
                        Not all NSR and title V permits are processed sequentially. Before discussing more streamlined permit issuance mechanisms, it is important to recognize that the NSR and title V permitting programs are based on distinct federal and state statutory and regulatory authorities and feature significant differences in both their substantive and procedural requirements. However, the two programs do feature some overlapping public participation requirements, including requirements for public notice, the opportunity for public comment, and the opportunity for judicial review. Accordingly, some state permitting authorities choose to streamline permit issuance by conducting one process that satisfies both sets of overlapping requirements. Based on the EPA's experience, the mechanisms that state permitting authorities use to streamline the permitting processes vary considerably across the nation. Different streamlining mechanisms have received various labels, including “combined,” “merged,” or “unified” permits.
                        <SU>90</SU>
                        <FTREF/>
                         This preamble addresses three of the more common forms of streamlining. For example, some permitting authorities streamline NSR and title V permit issuance by processing the two permits concurrently, subject to overlapping public participation opportunities.
                        <SU>91</SU>
                        <FTREF/>
                         There are two basic variations to this theme. First, the permitting authority could concurrently issue the NSR permit as a standalone document containing only NSR permit terms, and also issue a title V permit containing all existing title V permit terms as well as the new NSR permit terms. Or, second, the permitting authority could issue one permit document that contains both the NSR permit and title V permit conditions. Some permitting authorities employ a third mechanism, whereby the NSR permit is first issued with enhanced procedural and substantive requirements (based on title V requirements), and then the NSR permit requirements are subsequently incorporated into a title V permit through an administrative amendment process that does not require public participation.
                    </P>
                    <FTNT>
                        <P>
                            <SU>90</SU>
                             The EPA considers it more appropriate to refer to the results of such streamlining as a combined “permit,” as opposed to a combined “program.” This is because, although a single 
                            <E T="03">permit</E>
                             document may be used to satisfy both NSR and title V permitting requirements, the requirements of the NSR and title V 
                            <E T="03">programs</E>
                             are legally distinct. 
                            <E T="03">See Riverview Order</E>
                             at 25-26.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>91</SU>
                             This process is similar to another mechanism for permit streamlining (not directly implicated by this rulemaking), under which a permitting authority may consolidate two procedures associated with title V permit issuance: the public's review of a draft permit and the EPA's review of a proposed permit. 
                            <E T="03">See</E>
                             40 CFR 70.8(a)(1)(ii).
                        </P>
                    </FTNT>
                    <P>
                        The first approach—featuring separate NSR and title V permit documents issued at or around the same time—is undoubtedly the clearest of the various streamlining approaches. There can be no mistaking the fact that there are two legally distinct permit actions, and it is simple to identify which requirements are based on the NSR regulations (and thus not subject to additional review through title V).
                        <SU>92</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>92</SU>
                             
                            <E T="03">See South Louisiana Methanol Order</E>
                             at 9; 
                            <E T="03">SSS/WP Order</E>
                             at 14-15.
                        </P>
                    </FTNT>
                    <P>
                        The second approach is also viable, provided the underlying authority for the NSR aspects of the permit document are readily ascertainable from the permit(s) and permit record(s). 
                        <E T="03">See</E>
                         40 CFR 70.6(a)(1)(i). As explained in detail in several petition orders,
                        <SU>93</SU>
                        <FTREF/>
                         even where NSR and title V permit authorizations are contained within one permit document, such a permit action actually reflects two legally distinct permit actions by the state: (i) a preconstruction permit issued under the EPA-approved title I SIP regulations governing NSR, and (ii) an operating permit under EPA-approved part 70 regulations governing title V. Again, NSR permits and title V permits are based on differing statutory and regulatory schemes, and although the two programs feature similarities, they also feature important substantive and procedural differences. A permitting authority's decision to increase administrative efficiency by issuing a single permit document to satisfy the legal requirements of two distinct permitting programs does not alter the applicability of requirements associated with each respective program. For example, substantive requirements unique to NSR would not be applied to establish or evaluate non-NSR-based title V permit terms. Likewise, procedural requirements unique to title V (including the EPA's objection authority and public petition opportunity, among other things) would not be extended to review substantive elements of the permit action unique to the NSR permitting process. The EPA's objection authority, and the public's ability to petition EPA to object, are confined by the CAA to title V permits. 
                        <E T="03">See</E>
                         42 U.S.C. 7661d(b). Combining the procedures by which a permitting authority issues NSR and title V permits does not alter this basic principle.
                    </P>
                    <FTNT>
                        <P>
                            <SU>93</SU>
                             
                            <E T="03">See Waelz Order</E>
                             at 13-15; 
                            <E T="03">Riverview Order</E>
                             at 24-28; 
                            <E T="03">Yuhuang II Order</E>
                             at 7-8; 
                            <E T="03">Big River Steel Order</E>
                             at 11-12.
                        </P>
                    </FTNT>
                    <P>
                        The EPA appreciates that the combined-permit approach has the potential to introduce more confusion about which types of issues can be raised through different public participation avenues. In general, provided the permitting authority complies with existing regulatory requirements, the EPA believes this 
                        <PRTPAGE P="1168"/>
                        confusion can be minimized. First, the public could comment on all portions of a combined permit document during the comment period associated with the combined permit document. Similarly, all portions of a combined permit document could be challenged in a state court appeal of the final permit action.
                        <SU>94</SU>
                        <FTREF/>
                         Beyond that, the available mechanisms to challenge different permitting decisions would diverge. The EPA's 45-day review of the proposed permit, and the subsequent public petition opportunity, would apply only to title V-related aspects of the permit action. Likewise, unique oversight tools associated with title I permits (
                        <E T="03">e.g.,</E>
                         the EPA's authority under CAA section 167 to order a stop in work) would only apply to title I-related aspects of the permit action.
                    </P>
                    <FTNT>
                        <P>
                            <SU>94</SU>
                             Provisions governing the right to appeal final title V permits in state court is provided by 42 U.S.C. 7661a(b)(6) and 40 CFR 70.4(b)(3)(x)-(xii). For a discussion of equivalent opportunities to challenge title I permits in state court, see section IV.C.2. of this preamble.
                        </P>
                    </FTNT>
                    <P>
                        Differentiating between NSR-based and title V-based permit terms in a combined permit should be straightforward, as all title V permits “shall specify and reference the origin of and authority for each term or condition, and identify any difference in form as compared to the applicable requirement upon which the term or condition is based.” 40 CFR 70.6(a)(1)(i).
                        <SU>95</SU>
                        <FTREF/>
                         Thus, any NSR-related terms should be readily distinguishable from any non-NSR-related terms (or any title V-related terms related to monitoring and compliance assurance). The substance of appropriately designated NSR-based permit terms should not be subject to additional scrutiny through the unique title V oversight tools.
                    </P>
                    <FTNT>
                        <P>
                            <SU>95</SU>
                             This requirement is important in all situations where NSR permit terms (and permit terms derived from other CAA programs) are incorporated into a title V permit. However, it is especially important when NSR permit authorizations are issued within the same document as a title V permit in the first instance.
                        </P>
                    </FTNT>
                    <P>
                        Although the EPA's approach generally applies the same regardless of whether NSR and title V permits are sequentially or concurrently issued, there are important qualifications to this principle. Most notably, NSR permits must be finalized by the time the title V permit is finalized in order to establish the “applicable requirements” for title V purposes.
                        <SU>96</SU>
                        <FTREF/>
                         Moreover, it is critically important that concurrently issued permits (including combined permit documents) are clear as to the nature of, and the legal authority underlying, the permit actions reflected therein. This principle applies to the public notice announcing such permit action, other portions of the permit record available for public review, and the terms of the permit(s). 
                        <E T="03">See, e.g.,</E>
                         40 CFR 70.7(h)(2), 70.7(a)(5), 70.6(a)(1)(i). Where NSR and title V permit documents have been merged to such an extent that it is impossible to legally distinguish the NSR permit action from the title V permit action, it may be necessary to use the title V process to review whether the NSR-related requirements of the SIP are included in the title V permit. The next subsection elaborates on these and other situations in which NSR issues would be subject to review through title V oversight tools.
                    </P>
                    <FTNT>
                        <P>
                            <SU>96</SU>
                             Although the regulatory definition of “applicable requirement” includes “requirements that have been promulgated or approved by EPA through rulemaking at the time of issuance but have future-effective compliance dates,” 40 CFR 70.2, 71.2, this only covers future-effective requirements that have already been finalized at the time of title V permit issuance.
                        </P>
                    </FTNT>
                    <P>
                        A third process used by some permitting authorities is often described as “enhanced NSR.” The EPA's existing regulations allow requirements from an NSR permit issued with certain enhancements to be incorporated into a title V permit via administrative amendment procedures (instead of a significant modification or minor modification procedures, which would otherwise be required). To qualify for this type of streamlined processing, the NSR permit would need to be issued following “procedural requirements substantially equivalent to the requirements of [40 CFR] 70.7 and 70.8 . . . that would be applicable to the change if it were subject to review as a permit modification, and compliance requirements substantially equivalent to those contained in [40 CFR] 70.6.” 40 CFR 70.7(d)(1)(v); 
                        <E T="03">see</E>
                         71.7(d)(1)(v).
                    </P>
                    <P>
                        This third pathway has the potential to create confusion—and to conflict with the EPA's current (and proposed) approach—because the language quoted earlier may be read to mean that the EPA's objection authority and the public petition opportunity in 70.8(d) apply to the 
                        <E T="03">issuance of the NSR permit.</E>
                        <SU>97</SU>
                        <FTREF/>
                         This result is problematic for multiple reasons. For one, the CAA only provides the EPA with authority to object to the issuance of title V permits, not NSR permits. Similarly, the statutory obligation for the EPA Administrator to respond to petitions under CAA section 505(b)(2) only applies to petitions on title V permits. 42 U.S.C. 7661d(b)(2). Moreover, even if the EPA were to object to the issuance of an NSR permit, the EPA generally lacks authority to enforce such objection, as the EPA cannot issue the NSR permit if the state does not resolve the EPA's objection. Again, the authority to do so only relates to title V permits. 42 U.S.C. 7661d(c). Further, the existence of this process creates more confusion about the scope of issues properly subject to review during the NSR permitting action than the other two streamlined pathways. This is because it may be more difficult to distinguish title I and title V components within a single “enhanced NSR” permit.
                        <SU>98</SU>
                        <FTREF/>
                         Based on the preamble of the EPA's 1992 title V rules, it appears that the EPA's original intention when promulgating this mechanism was to generally confine EPA's review to the title V-based components of the enhanced NSR permit (
                        <E T="03">i.e.,</E>
                         the compliance requirements in 40 CFR 70.6).
                        <SU>99</SU>
                        <FTREF/>
                         However, contradictory positions taken by EPA in subsequent years has created confusion.
                        <SU>100</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>97</SU>
                             The EPA observes that some permitting authorities have EPA-approved SIP and/or title V program rules that differ from the EPA's regulations in this respect. Specifically, some EPA-approved state rules reserve the EPA's objection authority and public petition opportunity until the title V permit is administratively amended. This arrangement features less potential for confusion and less conflict with the EPA's current (and proposed) approach. 
                            <E T="03">See AK Steel Order</E>
                             at 10-12.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>98</SU>
                             For similar reasons, this process could cause difficulties with respect to allocating title V permit fees consistent with 40 CFR 70.9.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>99</SU>
                             
                            <E T="03">See</E>
                             57 FR at 32289 (“The primary intent of these `enhancements' of the NSR process is to allow the permitting authority to consolidate NSR and title V permit revision procedures. As stated in the May 10, 1991 proposal, it is not to second-guess the results of any State NSR determination. For example, if a State does provide for EPA's 45-day review in its NSR program, EPA would only be reviewing whether the State had conducted a BACT analysis, if applicable, and whether that analysis is faithfully incorporated in the title V permit. The EPA will not use its review period to object to or attempt to revise the State's BACT determination. Correspondingly, EPA's failure to object to the substance of the BACT determination will not limit any remedies EPA might-otherwise have under the Act to address a faulty BACT determination.”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>100</SU>
                             
                            <E T="03">See, e.g., In the Matter of Alon USA, Bakersfield Refinery,</E>
                             Order on Petition No. IX-2014-15 at 2-7 (Dec. 21, 2016).
                        </P>
                    </FTNT>
                    <P>
                        Although this third pathway reflected the EPA's attempt to allow for the streamlining of NSR and title V permit procedures, it raises more issues than it solves, and ultimately it is not necessary. The other two streamlining mechanisms—concurrent issuance of NSR and title V permits either in separate documents or in a single combined permit document—cause fewer problems and provide more advantages. Specifically, concurrent issuance mechanisms are compatible with the EPA's current (and proposed) approach to the title I/title V interface, while the “enhanced NSR” mechanism appears to erroneously suggest that the EPA has authority to directly object to title I permits. Additionally, concurrent 
                        <PRTPAGE P="1169"/>
                        issuance mechanisms allow permitting authorities to more clearly delineate the title I and title V permit actions, providing more clarity to the public about which issues may be challenged through different review pathways. Finally, concurrent issuance mechanisms are more efficient than the enhanced NSR mechanism, as permitting authorities need not take an additional, separate title V administrative amendment action after issuing an NSR permit.
                    </P>
                    <P>For the foregoing reasons, the EPA proposes to remove from its regulations the provisions relating to enhanced NSR permitting and related title V administrative amendments. The EPA solicits comment on whether state permitting authorities should remove equivalent regulations from their EPA-approved program rules, although the EPA does not anticipate such actions will be necessary. Instead, it should be sufficient for permitting authorities to simply stop using this mechanism in a manner that purports to provide an EPA objection authority and public petition opportunity directly on an NSR permit. In any case, the EPA generally will not use its objection authority to address the substance of NSR permitting decisions made through this process.</P>
                    <P>The EPA specifically requests comments regarding additional mechanisms that permitting authorities use to streamline the issuance of NSR and title V permits. The EPA requests comments about how these differing approaches might impact, or be impacted by, the EPA's current (and proposed) approach.</P>
                    <HD SOURCE="HD3">5. Situations in Which the Title V Process Will Be Used To Review NSR Issues</HD>
                    <P>
                        There are certain situations in which the title V permitting process 
                        <E T="03">is</E>
                         the appropriate venue for addressing NSR permitting issues. This conclusion is supported by the same statutory and regulatory interpretations underlying situations in which the title V permitting process is 
                        <E T="03">not</E>
                         appropriate for addressing NSR permitting issues. In sum, as explained further in the following subsections, where applicable requirements are conclusively established under another CAA program, they are 
                        <E T="03">not</E>
                         substantively addressed through title V. Where applicable requirements are not conclusively established under another CAA program, they 
                        <E T="03">are</E>
                         substantively addressed through title V. Where the requirements of another CAA program and the requirements of title V feature substantive overlap, such areas of overlap 
                        <E T="03">are</E>
                         addressed through title V.
                    </P>
                    <HD SOURCE="HD3">a. No Permit Issued Through a Title I Permitting Process With Public Notice and the Opportunity for Comment and Judicial Review</HD>
                    <P>
                        Under the EPA's current (and proposed) framework, title I permits issued with public notice and the opportunity for comment and judicial review conclusively establish NSR-related “applicable requirements” of the SIP (or FIP) for title V purposes. But if NSR permitting decisions are not developed through a formal process that involves public notice and the opportunity for comment and judicial review, the public and the EPA have no opportunity to provide input on, or appeal, whether the relevant NSR requirements were properly established. In this circumstance, it would be inappropriate to simply incorporate any such NSR requirements into a title V permit without further review. In other words, where NSR-related requirements are not established through a public title I permitting process with an opportunity for judicial review, the applicable requirements of the SIP (or FIP) relevant to the construction project at issue are not yet conclusively defined for title V purposes.
                        <SU>101</SU>
                        <FTREF/>
                         In such a situation, the title V process can and should be used to assure compliance with the relevant underlying NSR-related applicable requirements of the SIP (or FIP). This approach is similar to how the title V process is used to define the specific requirements necessary to assure compliance with general requirements of other CAA programs that are not definitively established through a separate rulemaking or permitting process, as discussed in section III.F. of this preamble.
                    </P>
                    <FTNT>
                        <P>
                            <SU>101</SU>
                             As explained further in section IV.C.1. of this preamble, this view relates only to how an NSR permit is treated during the title V permitting process. It does not in any way affect the independent enforceability of the NSR permit itself.
                        </P>
                    </FTNT>
                    <P>
                        The title V process can be used to review NSR issues in various situations, some of which the EPA has confronted in recent years. For example, the EPA has reviewed, and will continue to review, substantive NSR issues where no title I permit is issued to authorize the projects at issue.
                        <SU>102</SU>
                        <FTREF/>
                         The title V process can be used to ensure that any new or modified sources that do not obtain an NSR permit (sometimes called “unpermitted projects”) comply with all relevant NSR-related requirements of the SIP (or FIP).
                    </P>
                    <FTNT>
                        <P>
                            <SU>102</SU>
                             
                            <E T="03">See Suncor East Order</E>
                             at 45-48, 54-55 (reviewing NSR issues where the state “has not issued any title I NSR permits that would establish the NSR-related `applicable requirements' of the SIP”); 
                            <E T="03">SRP Agua Fria Order</E>
                             at 11 n.18 (reviewing NSR applicability issues where no NSR permit had been issued); 
                            <E T="03">SRP Desert Basin Order</E>
                             at 12 n.20 (same); 
                            <E T="03">BP Whiting II Order</E>
                             at 13 n.24 (reviewing an NSR-related emission limit that was established in a title V, as opposed to an NSR, permit action). Additionally, within a portion of the EPA's 2017 
                            <E T="03">PacifiCorp-Hunter I Order</E>
                             that was not challenged and not subject to the Tenth Circuit's partial vacatur, the EPA addressed the merits of a petition claim involving allegedly unpermitted modifications. 
                            <E T="03">See PacifiCorp-Hunter I Order</E>
                             at 26-31.
                        </P>
                    </FTNT>
                    <P>
                        If a preconstruction permit is issued, but not issued under title I—that is, not issued under NSR permitting rules that have been approved by EPA and incorporated into the SIP or FIP—then such a permit would not establish the NSR requirements of the SIP (or FIP) that apply to an individual source. Issuance of a non-title I permit does not reflect a determination as to which of the NSR requirements in a SIP (or FIP) apply to construction and thus does not fulfill any NSR requirements in the SIP (or FIP). In this situation, it would thus be appropriate to use the title V permitting process to assess whether there are NSR requirements in the SIP (or FIP) that apply to a construction project covered by a non-title I permit. Moreover, it would be appropriate to use the title V permitting process to explore whether a preconstruction permit was issued under a title I-based authority, as opposed to a non-title I authority.
                        <SU>103</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>103</SU>
                             For example, within a portion of the EPA's 2017 
                            <E T="03">PacifiCorp-Hunter I Order</E>
                             that was not challenged and not subject to the Tenth Circuit's partial vacatur, the EPA addressed the merits of a petition claim involving a NSR permit that was allegedly not issued under EPA-approved SIP rules. 
                            <E T="03">See PacifiCorp-Hunter I Order</E>
                             at 24. Determining the authority underlying a preconstruction permit could also be relevant in other title V contexts. For example, states may issue preconstruction permits under state-only-enforceable laws (as opposed to federally-approved and federally-enforceable state laws, or federal laws). Such state-only permit requirements may be included in title V permits, but they must be labeled as “state-only” or “not federally enforceable” within a title V permit. 40 CFR 70.6(b)(2). Questions about the authority underlying such permits would therefore be relevant to determining whether 40 CFR 70.6(b)(2) was satisfied. 
                            <E T="03">See, e.g., In the Matter of Phillips 66 Co., Borger Refinery,</E>
                             Order on Petition No. VI-2017-16 at 8-10 (Sept. 22, 2021).
                        </P>
                    </FTNT>
                    <P>
                        The EPA has also reviewed, and will continue to review, substantive NSR issues where the underlying NSR permit was not issued following public notice and the opportunity for comment and judicial review.
                        <SU>104</SU>
                        <FTREF/>
                         As previously explained, this is because an NSR permit that is not issued following such procedures does not provide the title V 
                        <PRTPAGE P="1170"/>
                        permit writer or public with sufficient assurance that the preconstruction permitting process has conclusively established the applicable NSR requirements of the SIP (or FIP) for that source for title V purposes. Thus, questions about the procedures used to issue NSR permits may be indirectly relevant to the EPA's review of title V permits or public petitions on title V petitions.
                        <SU>105</SU>
                        <FTREF/>
                         Specifically, such questions may inform whether it is appropriate to use the title V process to review the substance of that NSR permit in order to ensure that the title V permit reflects, and assures compliance with, all relevant NSR applicable requirements of the SIP (or FIP). It is important to recognize that procedural problems associated with the issuance of an NSR permit would simply present a basis for EPA to review the underlying NSR issues; such procedural problems would not present an independent basis for the EPA's objection to the title V permit.
                        <SU>106</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>104</SU>
                             
                            <E T="03">See Suncor East Order</E>
                             at 48 (reviewing NSR-related issues where “the current title V renewal proceeding is the first permit action in which these NSR issues have been subject either to public notice and comment or the opportunity for judicial review,” among other reasons); 
                            <E T="03">Coyote Station Order</E>
                             at 12 (reviewing NSR-related issues “where no public notice was provided of the underlying NSR permit action,” among other reasons).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>105</SU>
                             To the extent the public raises procedural issues related to NSR permit issuance in a title V petition, petitioners have the burden to demonstrate that the correct process was not followed, similar to all other title V petition issues. 42 U.S.C. 7661d(b)(2); 
                            <E T="03">see</E>
                             40 CFR 70.12(a)(2).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>106</SU>
                             As explained in section IV.B.3. of this preamble, procedural requirements associated with NSR permit issuance are neither “applicable requirements” for title V purposes (because they do not apply to emission units at a part 70 source), nor are they part 70 requirements (because they are not related to the issuance of a specific title V permit).
                        </P>
                    </FTNT>
                    <P>
                        It is also important to recognize that, in proposing to add text to parts 70 and 71 referencing “public notice and the opportunity for public comment and judicial review” of NSR permits, this proposed rule would simply establish a precondition relevant to whether underlying NSR permits are insulated from, or subject to, additional review through title V. These proposed regulatory revisions will not impose any binding procedural requirements governing a permitting authority's issuance of NSR permits. Rather, such procedural requirements are found in the relevant statutory and regulatory authorities governing NSR, and the SIP regulations that implement them. 
                        <E T="03">See, e.g.,</E>
                         42 U.S.C. 7475(a)(2); 40 CFR 51.161, 51.165(i), 51.166(q). Although the proposed additions to parts 70 and 71 use language similar to existing requirements in the NSR rules, this proposed rule does not seek to define those concepts in the context of NSR. Rather, outside of this title V proposed rule, the EPA is reviewing opportunities for public participation in minor NSR permitting.
                    </P>
                    <P>For title V purposes, provided an NSR permit is issued following public notice, the opportunity to comment, and the opportunity for judicial review, the EPA will consider that NSR permit as establishing the relevant applicable requirements of the SIP with respect to the activities being permitted. Accordingly, the title V permitting process will not be used to second-guess the substance of those requirements. By codifying such criteria through the current proposed rule, the EPA's intent is not to create new requirements on NSR permitting, but rather to create an incentive for permitting authorities to offer robust opportunities for public involvement on NSR permit actions. In this manner, this proposed rule will reinforce existing requirements governing public participation on NSR permits and will complement the EPA's ongoing efforts to improve public participation in minor NSR permitting decisions.</P>
                    <HD SOURCE="HD3">b. Issues Involving Overlapping Title V and NSR Requirements</HD>
                    <P>The EPA has reviewed (and will continue to review) issues involving an overlap of title V and NSR requirements. The most notable example involves using title V to evaluate the sufficiency of monitoring and related compliance assurance requirements associated with more substantive NSR permit requirements. As the EPA explained in one title V petition order:</P>
                    <EXTRACT>
                        <P>
                            Unlike the BACT determination claims discussed above, claims concerning whether a title V permit contains enforceable permit terms, supported by monitoring sufficient to assure compliance with an applicable requirement or permit term (such as an emission limit established in a PSD permit), are properly reviewed during title V permitting. The statutory obligations to ensure that each title V permit contains “enforceable emission limitations and standards” supported by “monitoring . . . requirements to assure compliance with the permit terms and conditions,” 42 U.S.C. 7661c(a), (c), apply independently from and in addition to the underlying regulations and permit actions that give rise to the emission limits and standards that are included in a title V permit. Therefore, the EPA will address the merits of those portions of the Petition that challenge the enforceability of emission limits and the sufficiency of monitoring conditions in the Permit.
                            <SU>107</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>107</SU>
                                 
                                <E T="03">South Louisiana Methanol Order</E>
                                 at 10-11; 
                                <E T="03">see Gulf Coast Growth Ventures Order</E>
                                 at 17-19; 
                                <E T="03">ExxonMobil Baytown Chemical Order</E>
                                 at 20-21; 
                                <E T="03">Yuhuang II Order</E>
                                 at 8; 
                                <E T="03">see also, e.g., Big River Steel Order</E>
                                 at 17, 17 n.30, 19 n.32, 20; 
                                <E T="03">PacifiCorp-Hunter I Order</E>
                                 at 16, 17, 18, 18 n.33, 19.
                            </P>
                        </FTNT>
                    </EXTRACT>
                    <P>
                        The EPA has also considered (and will continue to consider) other issues involving an explicit overlap between NSR and title V. Examples addressed to date include situations where a state's SIP rules and part 70 program rules explicitly require consideration of NAAQS impacts in a title V permit proceeding; 
                        <SU>108</SU>
                        <FTREF/>
                         where both SIP and part 70 rules require an evaluation of the scope of the “stationary source” or “major source” subject to permitting requirements; 
                        <SU>109</SU>
                        <FTREF/>
                         and where SIP rules explicitly require consideration of adjustments to a PAL (a type of NSR permitting mechanism) in a title V renewal permit action.
                        <SU>110</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>108</SU>
                             
                            <E T="03">Suncor East Order</E>
                             at 53-54.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>109</SU>
                             
                            <E T="03">Coyote Station Order</E>
                             at 12-13.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>110</SU>
                             
                            <E T="03">ExxonMobil Baytown Chemical Order</E>
                             at 13-14.
                        </P>
                    </FTNT>
                    <P>
                        Notably, the EPA's consideration of NSR-related issues within these past actions did not involve reevaluating or second-guessing the content of applicable requirements established in NSR permitting actions. Instead, the EPA's consideration of those issues was based either on unique requirements of title V (
                        <E T="03">e.g.,</E>
                         to add supplemental monitoring to the requirements in underlying applicable requirements) or on directives within the SIP itself, which effectively provided a mandate to further define applicable requirements of the SIP through the title V process (instead of the NSR process). Thus, the limited situations in which the EPA does use (and proposes to continue using) the title V process to address NSR-related issues is wholly consistent with the EPA's position that, in general, the title V process should not be used to second-guess or alter substantive applicable requirements that are established through a title I permitting process with public notice and the opportunity for comment and judicial review.
                    </P>
                    <HD SOURCE="HD3">6. Summary of Proposed Regulatory Changes</HD>
                    <P>In order to more clearly express the EPA's current approach to the interface between NSR permits and title V permits, the EPA proposes the following amendments to the EPA's regulations.</P>
                    <P>
                        The EPA proposes to update paragraphs (1) and (2) of the definition of “applicable requirement” in 40 CFR 70.2 and 71.2. Paragraph (1) addresses SIP (and FIP) requirements more generally. This rule would add text to paragraph (1) to clarify that, for purposes of title V, where an NSR permit is issued under an EPA-approved or EPA-promulgated title I program (
                        <E T="03">i.e.,</E>
                         SIP or FIP), with public notice and the opportunity for comment and judicial review, then the terms and conditions of that preconstruction permit define the NSR-related applicable requirements of the SIP or FIP that apply to the activities 
                        <PRTPAGE P="1171"/>
                        authorized by such a preconstruction permit.
                    </P>
                    <P>This rule would also add text to paragraph (2) to clarify that, for purposes of title V, the relevant terms and conditions of all types of NSR permits issued under a SIP or FIP—including minor NSR permits—are applicable requirements that must be included in a title V permit, regardless of whether the procedures referenced in paragraph (1) are followed.</P>
                    <P>The EPA also proposes to remove the provisions in 40 CFR 70.7(d)(1)(v), 70.7(d)(4), 71.7(d)(1)(v), and 71.7(d)(4) that relate to the “enhanced NSR” and title V administrative amendment procedures, as discussed in section IV.B.4. of this preamble.</P>
                    <P>The EPA does not believe any additional changes to the regulations are necessary. However, the EPA requests comments on other changes to the regulatory text that would be necessary to fully effectuate the EPA's proposed approach.</P>
                    <HD SOURCE="HD2">C. Interaction With NSR Permitting, Oversight, and Enforcement</HD>
                    <P>Although this rulemaking addresses the intersection of the NSR and title V permitting programs, the EPA's proposed approach only directly affects implementation of the title V permitting program. More specifically, this rulemaking only affects the extent to which the title V permitting process will be used to assess whether issuance of an NSR permit complies with the NSR-related requirements of a SIP (or FIP). Thus, as explained in the following paragraphs, the EPA's proposed approach for limiting review of NSR permitting decisions through the title V process does not affect the independent validity or enforceability of NSR permit terms or the SIP (or FIP) requirements upon which they are based.</P>
                    <HD SOURCE="HD3">1. No Impact on the Independent Validity or Enforceability of NSR Permits</HD>
                    <P>
                        As discussed throughout this preamble, where an NSR permit is issued following public notice and the opportunity for comment and judicial review, the terms and conditions of such a permit establish the NSR-related applicable requirements of the SIP (or FIP) for title V purposes. Although these permit terms should generally be incorporated into the title V permit without further substantive review, an EPA decision not to conduct that review in the title V process does not mean that the EPA agrees that the state action complies with NSR requirements. It merely indicates that a title V permit is not the appropriate venue to correct any deficiencies in the NSR permit. Thus, even if EPA might find an error upon reviewing a preconstruction permitting decision made by the permitting authority, for purposes of the title V operating permit, the terms of the NSR permit should be incorporated into the title V operating permit until such time that there is a final action to revise, reopen, suspend, revoke, reissue, terminate, or invalidate the preconstruction permit, such as a court order in a state court appeal or through an enforcement action.
                        <SU>111</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>111</SU>
                             As explained previously, this approach is analogous to how the EPA treats potential defects in other types of applicable requirements, including (non-NSR) requirements of the SIP. For instance, even when the EPA has made a determination that a provision of the SIP is not in compliance with the Act, the EPA will not object to a permit that includes that provision until there is final action to remove it from the SIP. 
                            <E T="03">See, e.g., Piedmont Green Power Order</E>
                             at 28-29. EPA's lack of objection to the inclusion of that requirement in the title V permit does not indicate that the EPA agrees that it complies with the Act or applicable regulations; it merely indicates that a title V permit is not the appropriate venue to correct any such flaws in the SIP.
                        </P>
                    </FTNT>
                    <P>
                        By the same token, if an NSR permit is 
                        <E T="03">not</E>
                         issued through a process that included public notice and the opportunity for comment and judicial review, this proposed rule would not address whether such a permit is valid or enforceable in its own right. Rather, this proposed rule would only affect how such a permit is treated through title V. The terms of such a permit would still need to be included in the title V permit under item (2) of the EPA's regulatory definition of “applicable requirement.” However, any such permit terms (and underlying permit decisions) would not be sufficient to conclusively define the NSR-related “applicable requirements” of the SIP under item (1) of the EPA's regulatory definition. Therefore, questions about the whether the NSR permit satisfied the requirements of the SIP 
                        <E T="03">would</E>
                         be subject to review through the title V process. But that is the only consequence insofar as this proposed rule is concerned. Any relevant requirements of the SIP would remain fully enforceable, and the independent enforceability of any NSR permit issued without an opportunity for comment and judicial review would be determined on the basis of those requirements.
                    </P>
                    <HD SOURCE="HD3">2. Title I Oversight and Enforcement Authorities</HD>
                    <P>
                        Under the EPA's proposed approach for considering NSR permitting decisions through the title V permitting process, there are meaningful opportunities for the EPA and the public to review NSR preconstruction permitting decisions under title I of the CAA.
                        <SU>112</SU>
                        <FTREF/>
                         Congress provided various mechanisms for EPA and public oversight of NSR permitting decisions.
                    </P>
                    <FTNT>
                        <P>
                            <SU>112</SU>
                             If anything, this action has the potential to increase the availability of certain enforcement opportunities, as discussed in Section IV.C.4. of this preamble.
                        </P>
                    </FTNT>
                    <P>Specifically, Congress gave the EPA programmatic oversight authority under title I to disapprove state NSR permitting programs and call for revisions to those programs if the state's program does not satisfy federal statutory and regulatory authorities governing NSR. 42 U.S.C. 7410(a)(2)(C), 7410(k)(5). Further, if a state fails to properly implement its NSR program, the EPA can take additional actions. 42 U.S.C 7413(a)(2), (a)(5).</P>
                    <P>
                        In terms of reviewing individual title I permits, each SIP must provide for public notice and an opportunity for comment on proposed NSR permits in its preconstruction permit program. 42 U.S.C. 7475(a)(2); 40 CFR 51.161, 51.165(i), 51.166(q). The EPA may provide feedback on state-issued NSR permits through this process.
                        <SU>113</SU>
                        <FTREF/>
                         Inherent in this title I permitting scheme—and reflected in the congressional record for the 1977 CAA Amendments—is the understanding that the adequacy of state NSR permitting decisions would be subject to review in state administrative and judicial forums.
                        <SU>114</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>113</SU>
                             Title I of the CAA specifically contemplates that the “interested persons” who may comment on state-issued PSD permits include “representatives of the Administrator.” 42 U.S.C. 7475(a)(2).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>114</SU>
                             “In order to challenge the legality of a permit which a State has actually issued . . . a citizen must seek administrative remedies under the State permit consideration process, or judicial review of the permit in State court.” Staff of the Subcommittee on Environmental Pollution of the Senate Committee on Environment and Public Works, 95th Congress, 1st Session, A Section-by-Section Analysis of S. 252 and S. 253, Clean Air Act Amendments 36 (1977), reprinted in 5 Legislative History of the Clean Air Act Amendments of 1977 3892 (1977). Note that the U.S. Supreme Court has also acknowledged the primacy of state courts to adjudicate disputes over NSR permit terms. 
                            <E T="03">See Alaska Dep't of Env't Conservation</E>
                             v. 
                            <E T="03">EPA,</E>
                             540 U.S. 461, 490 n.14 (2004); 
                            <E T="03">see also id.</E>
                             at 491-94 (addressing the relationship between state court review of NSR permits and federal oversight tools related to NSR permits). The EPA has expressed similar views when approving individual NSR SIPs. 
                            <E T="03">See, e,g.,</E>
                             77 FR 65305, 65306 (Oct. 26, 2012) (The EPA “interpret[s] the CAA to require an opportunity for judicial review of a decision to grant or deny a PSD permit, whether issued by EPA or by a State under a SIP-approved or delegated PSD program.”).
                        </P>
                    </FTNT>
                    <P>
                        Congress also provided EPA and the public with various enforcement mechanisms to address non-compliance with title I permitting requirements on a facility-by-facility basis. The EPA possesses the authority to issue 
                        <PRTPAGE P="1172"/>
                        injunctive orders to halt construction. 42 U.S.C. 7413(a)(5)(A), 7477. The EPA may also pursue various types of civil or criminal enforcement actions pursuant to sections 113 and 167 of the Act. 42 U.S.C. 7413, 7477. Under title III of the CAA, Congress also provided authority for citizens to bring enforcement actions seeking civil penalties and injunctive relief against a source that has violated certain NSR requirements. 
                        <E T="03">Id.</E>
                         7604(a)(1), (a)(3). These enforcement-based tools can be used to address situations where a source failed to obtain a required major NSR permit (even if it obtained a minor source permit). 
                        <E T="03">See e.g., U.S.</E>
                         v. 
                        <E T="03">S. Ind. Gas &amp; Elec. Co.,</E>
                         No. IP99-1692-CM/F, 2002 WL 1760699, at *3-5 (S.D. Ind. July 26, 2002); 
                        <E T="03">United States</E>
                         v. 
                        <E T="03">Ford Motor Co.,</E>
                         736 F. Supp. 1539, 1550 (W.D. Mo. 1990). They can also be used to ensure that decisions made in establishing the terms of a major NSR permit, such as BACT limits, were made on reasonable grounds properly supported by the record. 
                        <E T="03">See, e.g., Alaska Dep't of Env't Conservation</E>
                         v. 
                        <E T="03">EPA,</E>
                         540 U.S. 461 (2004) (affirming application of section 167 of the CAA in this context).
                    </P>
                    <HD SOURCE="HD3">3. Title V Permit Shields</HD>
                    <P>
                        The incorporation of the terms and conditions of an NSR permit into a title V permit does not, by itself, diminish the ability of the EPA or citizens to enforce preconstruction permitting requirements. However, enforcement could be affected by a title V “permit shield” imposed under CAA section 504(f) and 40 CFR 70.6(f) and 71.6(f). A permit shield, if part of an approved title V program and expressly included in a title V permit,
                        <SU>115</SU>
                        <FTREF/>
                         may provide a sufficient defense from enforcement actions under certain circumstances. This proposed rule does not change the agency's interpretation or enlarge the scope of a permit shield.
                    </P>
                    <FTNT>
                        <P>
                            <SU>115</SU>
                             “A part 70 permit that does not expressly state that a permit shield exists shall be presumed not to provide such a shield.” 40 CFR 70.6(f)(2).
                        </P>
                    </FTNT>
                    <P>There are two types of permit shields under title V. The first, default permit shield states that compliance with the title V permit “shall be deemed compliance with” title V. 42 U.S.C. 7661c(f). Where a facility is entitled only to this default permit shield, requirements of the CAA outside of title V (including NSR requirements) are still independently enforceable against the facility.</P>
                    <P>
                        A permitting authority may go further to provide a facility with a second, more expansive type of permit shield. This more expansive permit shield has two prongs. Under the first prong of an expanded permit shield, a permitting authority can provide that compliance with the title V permit “shall be deemed compliance with other [non-title V] applicable provisions,” but only if “the permit includes the applicable requirements of such provisions.” 42 U.S.C. 7661c(f)(1); 
                        <E T="03">see</E>
                         40 CFR 70.6(f)(1)(i). Where a title V permit includes this type of permit shield and also incorporates the terms of an NSR permit, the permit shield would provide that compliance with the title V permit would be deemed compliance with the specific applicable requirements reflected in the NSR permit. However, compliance with such a title V permit would 
                        <E T="03">not</E>
                         be deemed compliance with any other requirements that are not contained in the NSR permit. For example, if a source obtained a minor NSR permit for a project and the title V permit included this type of permit shield, compliance with the title V permit would not preclude an enforcement action alleging a violation of title I of the Act for failure to obtain a major NSR permit.
                    </P>
                    <P>
                        Under the second prong of an expanded permit shield, a permitting authority can only provide a shield from requirements it has expressly determined to be non-applicable. The statute and regulations say this shield is available if the state, “in acting on the [title V] permit application[,] makes a determination relating to the permittee that such other provisions (which shall be referred to in such determination) are not applicable and the permit includes the determination or a concise summary thereof.” 42 U.S.C. 7661c(f)(2); 
                        <E T="03">see</E>
                         40 CFR 70.6(f)(1)(ii). In other words, this type of permit shield requires that the permitting authority make a written non-applicability determination during the title V permitting process and memorialize this determination within the title V permit record.
                    </P>
                    <P>
                        Further, if a permitting authority chooses to include a title V permit shield that expressly covers NSR requirements that either are, or are not, applicable to a particular construction project, that decision would be based on title V authority and part of the title V permit action. As such, the NSR requirements covered by the title V permit shield would be subject to review and oversight through title V, including being subject to the EPA's objection authority and the public petition opportunity. The availability of these title V oversight tools is important because an express title V permit shield effectively precludes enforcement through the federal court system under CAA sections 113 or 304. By including an express permit shield through title V, that enforcement-based oversight tool is replaced by oversight through the title V permitting process, which provides an alternative pathway to the federal courts.
                        <SU>116</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>116</SU>
                             Specifically, if the EPA does not object to a title V permit on its own volition, and subsequently denies a petition requesting that the EPA object to the permit, such denial may be appealed to the relevant U.S. Court of Appeals. 42 U.S.C. 7661d(b)(2), 7607(b)(1).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">4. Other Enforcement Considerations</HD>
                    <P>
                        As one federal Court of Appeals explained: “Title V itself reserves the EPA's ability to bring an enforcement action for violations of the CAA unless an express `shield' on the face of the permit bars that action. This provision would hardly be necessary if the EPA was supposed to resolve all alleged violations of the CAA in the permitting process.” 
                        <E T="03">Citizens Against Ruining the Environment</E>
                         v. 
                        <E T="03">EPA,</E>
                         535 F. 3d 670, 678 (7th Cir. 2008) (quoting 42 U.S.C. 7661c(f)). However, other circuit courts have barred enforcement actions that they viewed as impermissible collateral attacks on permits.
                        <SU>117</SU>
                        <FTREF/>
                         In these cases, the courts' decisions were premised upon the notion that the EPA would assess the substantive validity or applicability of certain CAA requirements (including NSR requirements 
                        <SU>118</SU>
                        <FTREF/>
                        ) through the title V petition process, and that the EPA Administrator's decision in response to a title V petition could be challenged in federal court. Based on that premise, these courts decided that the jurisdictional bar in CAA section 307(b)(2) against “[a]ctions of the Administrator with respect to which review could have been obtained” applies to bar enforcement of these the substantive requirements underlying those enforcement actions. 42 U.S.C. 7607(b)(2). These decisions, however, did not identify statutory or regulatory text to support this premise; they may have been implicitly based on EPA practice from 1997 to 2017.
                    </P>
                    <FTNT>
                        <P>
                            <SU>117</SU>
                             
                            <E T="03">See Nucor Steel-Arkansas</E>
                             v. 
                            <E T="03">Big River Steel, LLC,</E>
                             825 F.3d 444 (8th Cir. 2016); 
                            <E T="03">EPA</E>
                             v. 
                            <E T="03">EME Homer City Generation, LP,</E>
                             727 F.3d 274 (3rd Cir. 2013); 
                            <E T="03">Sierra Club</E>
                             v. 
                            <E T="03">Otter Tail Power Co.,</E>
                             615 F.3d 1008 (8th Cir. 2010); 
                            <E T="03">Romoland School Dist.</E>
                             v. 
                            <E T="03">Inland Empire Energy Center, LLC,</E>
                             548 F.3d 738 (9th Cir. 2008).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>118</SU>
                             
                            <E T="03">See Nucor,</E>
                             825 F.3d at 452-53; 
                            <E T="03">Romoland,</E>
                             548 F.3d at 754-56.
                        </P>
                    </FTNT>
                    <P>
                        In light of the EPA's position since 2017 with respect to certain NSR permits, the premise underlying those cases no longer applies. Based on the interpretation of the title V provisions discussed in this proposal, the EPA's view is that the title V process does not operate to bar enforcement of the NSR permitting requirements on the basis of 
                        <PRTPAGE P="1173"/>
                        section 307(b)(2). This proposed rule will codify the EPA's current view that certain NSR issues are 
                        <E T="03">not</E>
                         subject to review through title V processes, including the petition process. Because the EPA Administrator will not consider or take any action concerning the substantive validity of these NSR permitting decisions through title V, there is no opportunity for federal judicial review of these issues through title V, and therefore the statutory bar in CAA section 307(b)(2) simply does not apply. Therefore, enforcement of certain NSR-related requirements in the district court should no longer be viewed as a collateral attack on an Administrator's action (or lack thereof) through title V for which review could have been obtained in an appellate court. At least one court that considered this issue since the EPA revised its interpretation in 2017 has declined to impose such a jurisdictional bar.
                        <SU>119</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>119</SU>
                             
                            <E T="03">See Sierra Club</E>
                             v. 
                            <E T="03">Entergy Arkansas LLC,</E>
                             503 F.Supp.3d 821, 847-48 (2020) (“In addition, plaintiffs maintain that the EPA's interpretation of statutory language such that it will no longer oversee state Title I permit decisions through Title V petitions provides an additional basis upon which the Court should decline to find and impose an exhaustion requirement. The Court has examined the allegations in the amended complaint and the briefing with respect to the specific provisions of the CAA under which plaintiffs bring claims and the alleged requirements for bringing those claims in federal court. The Court is satisfied at this stage of the litigation that the Court has subject matter jurisdiction over plaintiffs' claims in their amended complaint.”).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">D. Impacts of Proposed Action</HD>
                    <P>This proposed rule is primarily procedural in nature and does not impose any specific or direct requirements on any potentially affected stakeholders. Additionally, given that this proposed rule seeks to codify the EPA's existing policies and interpretations that have been in place since 2017, most of these effects will not arise from this regulatory action itself. The following paragraphs summarize the anticipated indirect impacts of EPA's current and proposed approach.</P>
                    <HD SOURCE="HD3">1. Impacts on the EPA</HD>
                    <P>This action most directly affects the EPA itself, and specifically the EPA's actions in overseeing both the title V and NSR permitting programs. This action will codify the EPA's current framework regarding the scope of issues that EPA will—and will not—review through unique title V permitting mechanisms, including the EPA's 45-day review of title V permits and the EPA's responses to citizen petitions challenging title V permits. Reflecting this existing approach more directly in regulations will provide consistency across the country and ensure that the EPA's permitting oversight resources are most effectively focused on the issues where such oversight can achieve the greatest results. For example, by not reviewing complex NSR issues through its title V oversight tools, the EPA can prioritize using those tools to ensure that title V permits assure compliance with substantive requirements established in other CAA programs, such as by requiring additional monitoring, recordkeeping, and reporting when necessary. This action further emphasizes the EPA's commitment to using its existing title I oversight tools to address title I permitting issues. As discussed in section IV.E.4.b. of this preamble, those title I oversight tools are more effective means of addressing title I issues than the EPA's title V oversight tools.</P>
                    <HD SOURCE="HD3">2. Impacts on State, Local, and Tribal Permitting Authorities</HD>
                    <P>This rule may also impact state, local, and Tribal permitting authorities that issue title V and/or NSR permits. From the EPA's experience, it appears that many, if not most, permitting authorities already implement their title V and NSR programs in a manner consistent with the EPA's current (and proposed) approach. That is, these permitting authorities do not use the title V permitting process to revisit NSR permitting decisions that they themselves previously made. For permitting authorities that have not been implementing the EPA's current approach, this action is expected to decrease administrative burdens. Permitting authorities should generally only have to address NSR-related permitting issues once: during the NSR permitting process.</P>
                    <P>
                        The EPA does not expect it will be necessary for most permitting authorities to revise their regulations or to submit revised part 70 regulations or SIP regulations for EPA approval as a result of this proposed rule. The EPA views its existing part 70 and part 71 regulations—and, by extension, the equivalent regulations in EPA-approved state rules—to be consistent with the EPA's existing (and proposed) approach. This proposed rule is intended to make EPA's regulations clearer. Nonetheless, permitting authorities that desire the greater certainty associated with the rule revisions proposed in this action are welcome to make changes to their regulations similar to those the EPA is proposing.
                        <SU>120</SU>
                        <FTREF/>
                         The EPA specifically solicits comments from permitting authorities about their ability (or inability) to implement the EPA's proposed approach without changes to their EPA-approved part 70 program rules.
                    </P>
                    <FTNT>
                        <P>
                            <SU>120</SU>
                             For example, states within the Tenth Circuit's jurisdiction may currently have language that matches the language in the EPA's regulation that the court considered in 
                            <E T="03">Sierra Club</E>
                             v. 
                            <E T="03">EPA,</E>
                             964 F.3d 882 (10th Cir. 2020). Once the EPA revises its own regulations, this should provide those states the certainty that the EPA will not use the title V process to address NSR issues, even within this jurisdiction. However, such states may wish to consider the extent to which the Tenth Circuit's reading of the same language affects their state law obligations with respect to the title V and NSR permitting interface.
                        </P>
                    </FTNT>
                    <P>The current proposed rule does not itself mandate any requirements governing the issuance of NSR permits. However, permitting authorities may choose to change some of their NSR permitting practices in order to realize benefits in their permitting programs. For example, in order to ensure that the EPA will not use its title V oversight tools to revisit a permitting authority's NSR permitting decisions, permitting authorities may increase the amount of public participation opportunities offered on minor NSR permit actions. The EPA strongly encourages permitting authorities to provide for robust and meaningful public participation opportunities on NSR permitting actions, consistent with existing statutory and regulatory requirements and EPA guidance.</P>
                    <P>Permitting authorities that currently process NSR and title permit actions through streamlined processes should consider the best way to achieve their administrative efficiency goals while maintaining the maximum amount of clarity regarding the distinctions between title I and title V permit actions. In particular, the EPA strongly encourages permitting authorities that currently employ an “enhanced NSR” framework to stop using such procedures and instead consider other mechanisms for streamlining. See section IV.B.4. of this preamble for additional information about how different streamlined permit issuance procedures impact the EPA's review of NSR issues through its title V authorities.</P>
                    <HD SOURCE="HD3">3. Impacts on Regulated Entities</HD>
                    <P>
                        As far as regulated entities are concerned, the approach described in this action increases certainty in final preconstruction permitting decisions. The additional regulatory text that EPA proposes to codify in this rulemaking should further increase such certainty. In order to take advantage of this increased certainty, the EPA expects that sources subject to both title V and NSR permitting programs will have an 
                        <PRTPAGE P="1174"/>
                        incentive to work with their permitting authorities to ensure that all relevant NSR permit actions are subject to robust and meaningful public participation opportunities.
                    </P>
                    <HD SOURCE="HD3">4. Impacts on the Public</HD>
                    <P>
                        The EPA expects that the public at large, including communities impacted by pollution from facilities regulated under the title V and NSR programs, will benefit from the increased clarity provided in this rulemaking, as well as from more effective engagement in NSR permitting decisions. A central focus of this effort is to more clearly define the most appropriate and effective routes for the public to participate in—and, if necessary, challenge—different types of CAA permitting decisions. In this manner, this rule does not limit meaningful public participation, but rather encourages 
                        <E T="03">more</E>
                         meaningful public participation by directing the public to the pathways that can be used to most effectively provide oversight over different types of permits.
                    </P>
                    <P>This rule will allow the public, permitting authorities, and the EPA to focus their title V-based efforts on issues that can be more fully and effectively addressed through title V, such as supplementing monitoring when necessary to assure compliance with underlying applicable requirements.</P>
                    <P>As explained in section IV.E.4.b. of this preamble, the title V permitting process has proven a generally ineffective mechanism to address deficiencies in NSR permitting actions. The available title I permitting and title III enforcement mechanisms are better tools for the public to utilize in addressing issues with NSR permitting decisions. The EPA's pre-2017 policies that ostensibly allowed the public to challenge NSR permit decisions through the title V process created a misleading incentive for the public to forego those more appropriate and effective title I appeal mechanisms. This process often resulted in the public investing considerable resources in pursuing title V-based challenges, which had limited effect on the permit terms at issue. As this proposed rule makes clear, the public's attention and resources would be more effectively deployed in challenges to NSR permits through the appropriate title I permitting and title III enforcement channels.</P>
                    <P>Additionally, the public should benefit from the incentives that this rule will create for states and regulated entities to ensure that relevant NSR permit actions involve public notice and the opportunity for comment and judicial review. These incentives will complement the related (but separate) actions that the EPA is considering with respect to minor NSR programs. Collectively, these actions should encourage increased public participation in the NSR permitting process.</P>
                    <P>To the extent that the public is deprived of meaningful opportunities to address NSR permit deficiencies, the title V permitting process should serve as a backstop so that the public (and the EPA) have the ability to ensure that title V permits contain the necessary NSR-related requirements.</P>
                    <P>The EPA solicits comment on examples of past situations (not hypothetical) where the EPA's objection to a title V permit helped address NSR-related issues that the public either did, or did not, have a chance to address through the NSR permitting process.</P>
                    <HD SOURCE="HD2">E. Rationale for Proposed Action</HD>
                    <P>As explained in the following subsections, title V of the CAA does not compel the EPA or state permitting authorities to use the title V operating permit process to review the substance of decisions made during the title I (NSR) preconstruction permitting process. The statute requires that title V permits assure compliance with “applicable requirements” of the CAA, but the statute does not define this term or expressly require that permitting authorities revisit NSR permitting decisions. The EPA interprets the statute to mean that the terms and conditions of a NSR permit issued under EPA-approved (or EPA-promulgated) title I rules, with public notice and the opportunity for comment and judicial review, define the relevant NSR-related applicable requirements of the SIP (or FIP) for purposes of title V permitting.</P>
                    <P>The EPA's interpretation is supported by the structure and purpose of title V. Congress designed title V to consolidate, assure compliance with, and improve the enforceability of applicable requirements established under other CAA programs. The title V program was not intended to create new substantive requirements or modify substantive requirements added in those other programs (other than to include supplemental compliance assurance measures, when necessary). This understanding of the purpose of title V—both in general and as it relates to the intersection of title V and NSR permitting—is reflected in the statute and regulations, the legislative history, EPA statements contemporaneous with the promulgation of the initial title V regulations, and various federal court decisions and EPA statements since that time.</P>
                    <P>The EPA's interpretation is also consistent with the structure of the CAA as a whole. The EPA's current (and proposed) approach gives weight to the title I mechanisms that Congress provided to establish the specific NSR-related requirements of SIPs, as well as the title I and title III procedures for evaluating, challenging, and enforcing title I permitting requirements. It also respects the system of cooperative federalism reflected in the NSR and title V permitting programs.</P>
                    <P>The EPA's current (and proposed) approach also reflects better policy than alternative interpretations because it: ensures that applicable requirements established in different CAA programs are treated consistently in title V permitting; better accounts for procedural, resource-related, and practical limitations associated with title V oversight tools; incentivizes the use of robust title I avenues of review; and respects the finality of NSR permitting decisions.</P>
                    <HD SOURCE="HD3">1. Statutory Text and Interpretation</HD>
                    <P>
                        The text of title V alone does not conclusively define the scope of issues subject to review (or re-review) during the title V permitting process. In relevant part, the CAA requires that title V permits “include enforceable emissions limitations and standards . . . and such other conditions as are necessary to assure compliance with applicable requirements of [the CAA], including the requirements of the applicable implementation plan,” 
                        <E T="03">i.e.,</E>
                         the SIP or FIP. 42 U.S.C. 7661c(a). Similarly, if the EPA determines that a title V permit is “not in compliance with the applicable requirements of [the CAA], including the requirements of an applicable implementation plan,” the EPA must object, and if the EPA does not, any person may petition the EPA to do so. 42 U.S.C. 7661d(b)(1)-(2).
                        <FTREF/>
                        <SU>121</SU>
                          
                        <PRTPAGE P="1175"/>
                        However, the term “applicable requirements” is not defined in the Act, and the statute does not otherwise specify how to determine the applicable requirements of the CAA or the SIP (or FIP) for a particular source.
                    </P>
                    <FTNT>
                        <P>
                            <SU>121</SU>
                             Similar requirements appear in other parts of title V. For example: “The term `schedule of compliance' means a schedule of remedial measures, including an enforceable sequence of actions or operations, leading to compliance with an applicable implementation plan, emission standard, emission limitation, or emission prohibition.” 42 U.S.C. 7661(3). “Nothing in this subsection shall be construed to alter the applicable requirements of this chapter that a permit be obtained before construction or modification.” 42 U.S.C. 7661a(a). Permitting authorities “have adequate authority to . . . issue permits and assure compliance . . . with each applicable standard, regulation, or requirement under this chapter.” 42 U.S.C. 7661a(b)(5). The regulations to implement the program shall include a “requirement that the applicant submit with the application a compliance plan describing how the source will comply with all applicable requirements under this chapter.” 42 U.S.C. 7661b(b). However, like section 504, these sections do not specify the scope of the term “applicable requirements” or how the permitting 
                            <PRTPAGE/>
                            authority or the EPA is to determine what the applicable requirements are for an individual source as part of its title V permit.
                        </P>
                    </FTNT>
                    <P>
                        With respect to title I preconstruction permits, the statutory term “applicable requirements” is particularly ambiguous. As explained further in section IV.E.3.a. of this preamble, during the preconstruction permitting process, permitting authorities determine which NSR requirements in the SIP (or FIP) are applicable (
                        <E T="03">e.g.,</E>
                         major NSR or minor NSR requirements) to new or modified sources, and derive the specific permit conditions (
                        <E T="03">e.g.,</E>
                         emission limitations and other standards) applicable to a given source or modification based on the general direction in the SIP. The public has the opportunity to provide comment on draft permits and also to seek review in state court. At the end of this NSR permitting process, the NSR permit terms reflect the NSR-related requirements of the SIP (or FIP) applicable to the new or modified source.
                    </P>
                    <P>The question, then, is whether the title V permitting process should be used to double-check—and re-check during every subsequent title V renewal permit—the substantive adequacy of applicable requirements established through NSR permitting decisions. In other words, the question is whether title V should be used to assess whether the requirements embodied in an NSR permit were properly derived from the general, overarching SIP (or FIP) provisions governing NSR.</P>
                    <P>
                        Title V of the CAA contains no language expressly mandating such a re-evaluation through title V. Notably, the Fifth Circuit found the CAA's silence on this topic a persuasive reason for upholding the EPA interpretation that is the basis for this proposed rule. 
                        <E T="03">Env't Integrity Project,</E>
                         960 F.3d at 248-49.
                        <SU>122</SU>
                        <FTREF/>
                         The statute's silence on this topic stands in contrast to the presence of more specific statutory mandates, such as the requirement that title V permits be used to add compliance assurance measures like monitoring, recordkeeping, and reporting requirements. 42 U.S.C. 7661c(c); 
                        <E T="03">see</E>
                         40 CFR 70.6(c)(1); 
                        <E T="03">Sierra Club</E>
                         v. 
                        <E T="03">EPA,</E>
                         536 F.3d at 680.
                    </P>
                    <FTNT>
                        <P>
                            <SU>122</SU>
                             Specifically, the court stated the following: “We find persuasive EPA's position that Title V lacks a specific textual mandate requiring the agency to revisit the Title I adequacy of preconstruction permits. Our own review of Title V confirms that it contains no such explicit requirement, nor any language guiding the agency on how to perform a review of that nature. The principle that a matter not covered is not covered is so obvious that it seems absurd to recite it. A number of cases have identified the 
                            <E T="03">casus omissus pro omisso habendus est</E>
                             canon, under which a statute should not be read to include matter it does not include. Here, Title V does not tell EPA to reconsider [NSR] in the course of Title V permitting. We reject Petitioners' position because there is a basic difference between filling a gap left by Congress' silence and rewriting rules that Congress has affirmatively and specifically enacted.” 
                            <E T="03">Env't Integrity Project,</E>
                             960 F.3d at 248-49 (cleaned up) (citing 
                            <E T="03">Lamie</E>
                             v. 
                            <E T="03">U.S. Tr.,</E>
                             540 U.S. 526, 538 (2004); 
                            <E T="03">Iselin</E>
                             v. 
                            <E T="03">United States,</E>
                             270 U.S. 245, 251 (1926); 
                            <E T="03">Yates</E>
                             v. 
                            <E T="03">Collier,</E>
                             868 F.3d 354, 369 (5th Cir. 2017); 
                            <E T="03">In re Miller,</E>
                             570 F.3d 633, 638-39 (5th Cir. 2009)).
                        </P>
                    </FTNT>
                    <P>
                        Moreover, the CAA's references to “applicable requirements” do not compel such a re-evaluation. Notably, the Fifth Circuit rejected the notion that this general term should be construed as “broad and sweeping,” or that this term should be read to mandate using title V to review of whether requirements in an NSR permit accurately reflect the requirements of a SIP. 
                        <E T="03">See Env't Integrity Project,</E>
                         960 F.3d at 249-250 (“[Petitioners] would effectively rewrite the clause to read: `a de novo reconsideration of the source's preconstruction permitting.' Surely, Congress would not have hidden that regulatory elephant in this residual mousehole.”).
                    </P>
                    <P>
                        In light of the statute's ambiguity, the EPA has adopted an interpretation of the statutory terms “applicable requirements” and “requirements of the applicable implementation plan.” 
                        <SU>123</SU>
                        <FTREF/>
                         The EPA's interpretation is that the terms and conditions of an NSR permit issued under EPA-approved (or EPA-promulgated) title I rules, with public notice and the opportunity for comment and judicial review, define the relevant set of “applicable requirements” for purposes of title V permitting. That is, the “requirements of an applicable implementation plan” relevant to a particular construction project are the requirements that the permitting authority determined to be applicable during the NSR permitting process, as reflected in the terms of such an NSR permit. Not only is this interpretation consistent with the statutory text, but the EPA also considers this to be the best interpretation in light of the structure and purpose of title V, the structure of the CAA as a whole, and other policy reasons, as explained in the following subsections of this preamble.
                    </P>
                    <FTNT>
                        <P>
                            <SU>123</SU>
                             This interpretation is reflected, in part, in the EPA's existing regulations. 40 CFR 70.2, 71.2. These existing regulations can be read to support the statutory interpretation explained in this preamble. However, in light of the Tenth Circuit's ruling (which held that the EPA's regulatory definition of “applicable requirement” precluded the EPA's approach), the EPA is proposing to amend the EPA's regulations to more clearly reflect the EPA's statutory interpretation. For further discussion of the EPA's interpretation of its existing regulations, see 
                            <E T="03">Big River Steel Order</E>
                             at 9-11.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">2. Structure and Purpose of Title V</HD>
                    <P>The EPA's interpretation of “applicable requirements” in the context of title V and NSR permitting is supported by the structure and purpose of the title V program—namely, to consolidate, assure compliance with, and improve the enforceability of applicable requirements established under other CAA programs. The title V program was not intended to establish new substantive requirements or modify substantive requirements created in other programs (other than to include supplemental compliance assurance measures, when necessary). This purpose is reflected in the statute and regulations, the legislative history associated with Congress's enactment of title V, EPA statements contemporaneous with the promulgation of the initial title V regulations, and various federal court decisions and EPA statements since that time.</P>
                    <P>As introduced in section III.B. of this preamble, a core purpose and function of title V is to identify, consolidate, and assure compliance with the requirements applicable to individual sources from other, more substantive CAA programs. This function is embodied primarily within CAA section 504 and 40 CFR 70.6(a) and (c), which generally require that title V permits include conditions that assure an individual source's compliance with all CAA applicable requirements.</P>
                    <P>When Congress enacted title V in 1990, it explained this purpose as follows:</P>
                    <EXTRACT>
                        <P>The first benefit of the title V permit program is that . . . it will clarify and make more readily enforceable a source's pollution control requirements. Currently, in many cases, the source's pollution control obligations . . . are scattered throughout numerous, often hard-to-find provisions of the SIP or other Federal regulations. . . . The air permit program will ensure that all of a source's obligations . . . will be contained in one permit document.</P>
                    </EXTRACT>
                    <FP>
                        S. Rep. No. 101-228 at 347 (Dec. 20, 1989), 
                        <E T="03">reprinted in</E>
                         5 Legislative History of the Clean Air Act Amendments of 1990 (CAA Legislative History) at 8687 (1998).
                        <SU>124</SU>
                        <FTREF/>
                    </FP>
                    <FTNT>
                        <P>
                            <SU>124</SU>
                             Other portions of the history of this legislation describe the purpose of title V in similar terms. 
                            <E T="03">See, e.g.,</E>
                             Conf. Rep. on S. 1630, Speech of Rep. Michael Bilirakis (Oct. 26, 1990), 6 CAA Legislative History at 10768 (1998).
                        </P>
                    </FTNT>
                    <P>
                        In addition to identifying and consolidating existing requirements 
                        <PRTPAGE P="1176"/>
                        applicable to a source, CAA section 504 provides the authority to use title V permits to establish additional requirements relating to compliance assurance. For example, it is well-established that title V permits may be used to create or supplement monitoring requirements when necessary to assure an individual source's compliance with underlying applicable requirements that do not themselves contain sufficient monitoring provisions.
                        <SU>125</SU>
                        <FTREF/>
                         This exception proves the rule; where Congress intended title V to serve as a vehicle for the reevaluation of existing requirements or for imposing new requirements, it expressly said so.
                    </P>
                    <FTNT>
                        <P>
                            <SU>125</SU>
                             
                            <E T="03">See</E>
                             42 U.S.C. 7661c(c); 40 CFR 70.6(c)(1); 
                            <E T="03">Sierra Club</E>
                             v. 
                            <E T="03">EPA,</E>
                             536 F.3d 673, 674-45, 680 (D.C. Cir. 2008) (“Title V did more than require the compilation in a single document of existing applicable emission limits and monitoring requirements. It also mandated that `[e]ach permit issued under [Title V] shall set forth . . . monitoring . . . requirements to assure compliance with the permit terms and conditions.' . . . [T]he Act requires: a permitting authority may supplement an inadequate monitoring requirement so that the requirement will `assure compliance with the permit terms and conditions.' ” (citations omitted)); 
                            <E T="03">see also, e.g., In the Matter of CITGO Refining and Chemicals Co., L.P., West Plant,</E>
                             Order on Petition No. VI-2007-01 at 6-8 (May 28, 2009). This additional purpose is similarly reflected in the legislative history. 
                            <E T="03">See, e.g.,</E>
                             S. Rep. No. 101-228 at 347, 5 CAA Legislative History at 8687. Various compliance assurance requirements are included within title V and the EPA's implementing regulations; not all are restricted to monitoring. 
                            <E T="03">See</E>
                             42 U.S.C. 7661c(a), (b), (c); 40 CFR 70.6(a)(1), (a)(3), (c), 71.6(a)(1), (a)(3), (c); 
                            <E T="03">see also, e.g., In the Matter of Suncor Energy (U.S.A.), Inc., Commerce City Refinery, Plant 2 (East),</E>
                             Order on Petition Nos. VIII-2022-13 &amp; VIII-2022-14 at 13-17 (July 31, 2023).
                        </P>
                    </FTNT>
                    <P>Beyond title V's consolidation and compliance assurance functions, it is axiomatic that title V generally does not impose new pollution control requirements on sources or provide a vehicle to modify such requirements established under other CAA programs. As stated in the congressional record:</P>
                    <EXTRACT>
                        <P>The permit provisions of title V provide a focus for this harmonization [of other titles of the CAA], although title V does not change, and gives EPA no authority to modify, the substantive provisions of these other titles. . . . [T]itle V does not change, and gives EPA no authority to modify, the substantive provisions of these other titles. . . . Title V creates no new substantive emission control requirements. Nothing in the permitting title should be read to increase the stringency of any control requirement nor to delay or accelerate the effectiveness of such requirements, except as expressly provided in titles I, III, and IV.</P>
                    </EXTRACT>
                    <FP>Conf. Rep. on S. 1630, Speech of Rep. Michael Bilirakis (Oct. 26, 1990), 6 CAA Legislative History at 10768 (1998).</FP>
                    <P>
                        Recognizing the core functions of the title V program, the EPA's regulations have provided since 1992: “All sources subject to these regulations shall have a permit to operate that assures compliance by the source with all applicable requirements. While 
                        <E T="03">title V does not impose substantive new requirements,</E>
                         it does require that fees be imposed on sources and that certain procedural measures be adopted especially with respect to compliance.” 40 CFR 70.1(b) (emphasis added). These principles are further explained in EPA statements contemporaneous with the initial 1992 title V regulations,
                        <SU>126</SU>
                        <FTREF/>
                         subsequent rulemakings,
                        <SU>127</SU>
                        <FTREF/>
                         and in numerous orders responding to petitions challenging individual title V permits.
                        <SU>128</SU>
                        <FTREF/>
                         Likewise, federal courts across the nation have acknowledged and reiterated these general principles.
                        <SU>129</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>126</SU>
                             
                            <E T="03">See</E>
                             57 FR at 32251 (“While title V generally does not impose substantive new requirements, it does require that . . . certain procedural measures be followed, especially with respect to determining compliance with underlying applicable requirements. The program will generally clarify, in a single document, which requirements apply to a source and, thus, should enhance compliance with the requirements of the Act. . . . The title V permit program will enable the source, States, EPA, and the public to understand better the requirements to which the source is subject, and whether the source is meeting those requirements. Increased source accountability and better enforcement should result.”); 
                            <E T="03">id.</E>
                             at 32284 (“As discussed above, title V is primarily procedural, and is not generally intended to create any new substantive requirements. . . . The title V permit is intended to record in a single document the substantive requirements derived from elsewhere in the Act. Therefore, in most cases the only emissions limits contained in the permit will be emissions limits that are imposed to comply with the substantive requirements of the Act (including SIP requirements).”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>127</SU>
                             
                            <E T="03">See</E>
                             81 FR 57822, 57826-27 (Aug. 24, 2016) (“For the most part, title V of the CAA does not impose new pollution control requirements on sources. The definition of `applicable requirements' in the part 70 regulations includes many standards and requirements that are established through other CAA programs, such as standards and requirements under sections 111 and 112 of the Act, and terms and conditions of preconstruction permits issued under the New Source Review programs. 40 CFR 70.2. Once those air quality control requirements are established in those other programs, they are incorporated into a source's title V permits as appropriate. . . . [I]n providing an opportunity for harmonization through title V of the CAA, Congress did not replace or remove the procedures and requirements for establishing substantive requirements that exist in other provisions of the CAA.”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>128</SU>
                             Hundreds of EPA petition orders include background discussion reiterating this core function of title V. Electronic copies of these orders are available on the EPA's public database, 
                            <E T="03">https://www.epa.gov/title-v-operating-permits/title-v-petition-database.</E>
                             To the extent individual petition orders contain particularly relevant discussion, they are discussed elsewhere in this preamble.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>129</SU>
                             
                            <E T="03">See, e.g., Utility Air Reg. Group</E>
                             v. 
                            <E T="03">EPA,</E>
                             573 U.S. 302, 309 (2014) (“Unlike the PSD program, Title V generally does not impose any substantive pollution-control requirements.”); 
                            <E T="03">Env't Integrity Project,</E>
                             960 F. 3d at 250 (“By all accounts, Title V's purpose was to simplify and streamline sources' compliance with the Act's substantive requirements. Rather than subject sources to new substantive requirements—or new methods of reviewing old requirements—the intent of Title V was to consolidate into a single document (the operating permit) all of the clean air requirements applicable to a particular source of air pollution.” (cleaned up)); 
                            <E T="03">id.</E>
                             at 244; 
                            <E T="03">see also, e.g., U.S. Sugar Corp.</E>
                             v. 
                            <E T="03">EPA,</E>
                             830 F.3d 579, 597 (D.C. Cir. 2016); 
                            <E T="03">US</E>
                             v. 
                            <E T="03">EME Homer City Generation, LP,</E>
                             727 F. 3d 274, 280 (3rd Cir. 2013); 
                            <E T="03">Sierra Club</E>
                             v. 
                            <E T="03">Johnson,</E>
                             541 F.3d 1257, 1260 (11th Cir. 2008); 
                            <E T="03">Sierra Club</E>
                             v. 
                            <E T="03">Leavitt,</E>
                             368 F.3d 1300, 1302 (11th Cir. 2004); 
                            <E T="03">Appalachian Power Co.</E>
                             v. 
                            <E T="03">EPA,</E>
                             208 F. 3d 1015, 1026-27 (D.C. Cir. 2000).
                        </P>
                    </FTNT>
                    <P>Not only were these general principles well-established at the inception of the title V program, but both Congress and the EPA specifically spoke to the manner in which these general principles would guide the interaction between title V and title I permitting programs. For example, a Senate Report accompanying title V explained:</P>
                    <EXTRACT>
                        <P>
                            New and modified major sources are already required to obtain construction permits under the [NSR] and [PSD] provisions of the current Act. 
                            <E T="03">EPA should avoid imposing additional construction permit requirements under title V.</E>
                             Thus, construction permits may continue to be issued under the existing provisions of the Act, but title V will apply with respect to existing source requirements not otherwise required in the construction permit, 
                            <E T="03">e.g.,</E>
                             fees.
                        </P>
                    </EXTRACT>
                    <FP>
                        S. Rep. No. 101-228 at 349, 5 CAA Legislative History at 8689 (emphasis added).
                        <SU>130</SU>
                        <FTREF/>
                         Thus, the legislative history articulates Congress's intent that, notwithstanding the enactment of title V, NSR permits would continue to be issued as they had for over a decade. Title V permits would be used to incorporate the requirements of NSR permits, but not to alter or impose additional NSR-related requirements.
                    </FP>
                    <FTNT>
                        <P>
                            <SU>130</SU>
                             Similarly, one lawmaker involved in the statute's enactment explained: “In the past, some provisions of the Clean Air Act—for example, the nonattainment and PSD new source requirements—were, 
                            <E T="03">and will continue to be,</E>
                             implemented through preconstruction permits.” Conf. Rep. on S. 1630, Speech of Rep. Michael Bilirakis (Oct. 26, 1990), 6 CAA Legislative History at 10768 (1998) (emphasis added).
                        </P>
                    </FTNT>
                    <P>
                        As previously noted, in the 1991 and 1992 preambles to the EPA's initial title V rules, the agency announced a similar understanding of the intersection of title V and title I permitting. The EPA did not express an intention to use the title V permitting process to review the applicable requirements established in preconstruction permitting programs under title I of the CAA. To the contrary, the EPA stated: “Any requirements established during the preconstruction review process also apply to the source for purposes of implementing title V. If the source meets the limits in its NSR permit, the title V operating permit would 
                        <PRTPAGE P="1177"/>
                        incorporate these limits 
                        <E T="03">without further review.</E>
                        ” 56 FR 21712, 21738-39 (May 10, 1991) (emphasis added). Similarly, the EPA explained: “The intent of title V is 
                        <E T="03">not to second-guess</E>
                         the results of 
                        <E T="03">any</E>
                         State NSR program.” 
                        <E T="03">Id.</E>
                         at 21739 (emphasis added). Further, “Decisions made under the NSR and/or PSD programs (
                        <E T="03">e.g.,</E>
                         [BACT]) 
                        <E T="03">define applicable SIP requirements</E>
                         for the title V source and, if they are not otherwise changed, can be incorporated 
                        <E T="03">without further review</E>
                         into the operating permit for the source. The title V program is not intended to interfere in any way with the expeditious processing of new source permits.” 
                        <E T="03">Id.</E>
                         at 21721 (emphasis added). The preamble to the final rule further confirms that “[d]ecisions made under the NSR and/or PSD programs 
                        <E T="03">define certain applicable SIP requirements</E>
                         for the title V source.” 57 FR at 32259 (emphasis added).
                    </P>
                    <P>
                        The EPA's contemporaneous interpretation of the statute (and the regulations implementing this statute), should be afforded great weight, as the Fifth Circuit acknowledged in 
                        <E T="03">Env't Integrity Project,</E>
                         960 F.3d at 251 (“We also agree with EPA that the language in part 70's preamble is probative of Title V's purpose as a whole.”).
                        <SU>131</SU>
                        <FTREF/>
                         Although the EPA departed from this interpretation during the 2000s, the EPA's return to this interpretation reflects a better construction of the statute and congressional intent.
                        <SU>132</SU>
                        <FTREF/>
                         As the Fifth Circuit stated: “We find persuasive EPA's view that, because Title V was not intended to add new substantive requirements to the Act, it should not be interpreted as Petitioners urge. . . . This goal, as EPA argues, is at cross-purposes with using the Title V process to reevaluate preconstruction permits.” 
                        <E T="03">Id.</E>
                         at 250-51.
                    </P>
                    <FTNT>
                        <P>
                            <SU>131</SU>
                             An agency's contemporaneous interpretation is often given great weight in understanding the meaning of a statute. 
                            <E T="03">See e.g., Good Samaritan Hosp.</E>
                             v. 
                            <E T="03">Shalala,</E>
                             508 U.S. 402, 414 (1993) (“Of particular relevance is the agency's contemporaneous construction which `we have allowed . . . to carry the day against doubts that might exist from a reading of the bare words of a statute.' ” (quoting 
                            <E T="03">FHA</E>
                             v. 
                            <E T="03">The Darlington, Inc.,</E>
                             358 U.S. 84, 90 (1958))).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>132</SU>
                             
                            <E T="03">See Env't Integrity Project,</E>
                             960 F.3d at 251 (“We recognize that EPA has reverted to its original interpretation of § 70.2, reflecting its changing views of Title V. We take the agency's change of position into account in determining whether to defer to its position. But even when `the agency has embraced a variety of approaches' we may still defer to its present position, `especially' when the current view `closely fits the design of the statute as a whole.' ” (quoting 
                            <E T="03">Shahala,</E>
                             508 U.S. at 417-18; additional citation omitted)).
                        </P>
                    </FTNT>
                    <P>Other statutory provisions within title V further support the EPA's interpretation. In enacting title V, Congress directed the EPA to “develop streamlined procedures in cases where the permit simply incorporates without changing[ ] existing requirements found in the SIP or in other provisions of the Act.” S. Rep. No. 101-228 at 353, 5 CAA Legislative History at 8693. Reflecting this directive, title V requires state programs to have “[a]dequate, streamlined, and reasonable procedures . . . for expeditious review of permit actions . . . .” 42 U.S.C. 7661a(b)(6). Requiring a permitting authority, or the EPA, to go back and review final permitting decisions that have already been subject to the safeguards of public notice and judicial review would frustrate the goal of “expeditious review of permit actions.”</P>
                    <P>
                        Similarly, Congress provided abbreviated timeframes for the EPA to review a proposed title V permit: 45 days for the EPA's independent review, and 60 days if confronted with a petition to object. 42 U.S.C. 7661d(b); 
                        <E T="03">see</E>
                         40 CFR 70.8(c), (d). Based on “the abbreviated timeline Congress gave EPA,” the Fifth Circuit in 
                        <E T="03">Env't Integrity Project</E>
                         concluded “that these timelines are inconsistent with an in-depth and searching review of every permitting decision regarding a given source.” 
                        <E T="03">Env't Integrity Project,</E>
                         960 F.3d at 251.
                        <SU>133</SU>
                        <FTREF/>
                         This point is compounded by the fact that title V permits must be renewed every 5 years. 42 U.S.C. 7661a(b)(5)(B), (b)(6); 
                        <E T="03">see, e.g.,</E>
                         40 CFR 70.6(a)(2). As the Fifth Circuit stated, “the fact that Title V permits must be renewed every 5 years tends to support the agency's view that Title V was not intended to serve as a vehicle for re-examining the underlying substance of preconstruction permits. Subjecting a source's preconstruction permit to periodic new scrutiny, without any changes to the source's pollution output, would be inconsistent with Title V's goal of giving sources more security in their ability to comply with the Act.” 
                        <E T="03">Env't Integrity Project,</E>
                         960 F.3d at 251-52.
                    </P>
                    <FTNT>
                        <P>
                            <SU>133</SU>
                             
                            <E T="03">See also Env't Integrity Project,</E>
                             960 F.3d at 253 (“Title I [includes] more detailed procedures for in-depth oversight of case-specific permitting decisions. Such permitting decisions follow state appeals or enforcement actions authorized by other provisions of the Act, including citizen suits under Title III. Those mechanisms are better structured to provide agency and citizen oversight of preconstruction permitting. . . . Title V contains none of the procedures that would guide those challenges, as Titles I and III do. . . . And those avenues provide more time for development and consideration of the potential issues.” (internal citations and quotations omitted)).
                        </P>
                    </FTNT>
                    <P>In summary, neither the structure of title V nor the congressional record indicate that Congress intended the EPA to reevaluate and rewrite substantive title I preconstruction requirements through the title V process. Title V was enacted largely to identify and consolidate the variety of requirements applicable to each facility and assure compliance with these requirements through provisions like monitoring, recordkeeping, and reporting. Reexamining title I permits through title V would not help address either of these objectives. Moreover, congressional intent for efficiency would be undermined if permitting authorities were required to second-guess complex decisions reflected in state-issued title I permits during title V review, and then re-check these decisions during each subsequent title V renewal. Such a review would also be generally incompatible with the limited timeframes that Congress provided for EPA's review of title V permits. These considerations related to the structure and purpose of title V align with the EPA's interpretations of the statute from the early 1990s, as well as the opinions of federal courts.</P>
                    <P>
                        All indications of congressional intent suggest that the EPA's role in oversight over the issuance of title V permits should be limited. In the case of preconstruction permitting requirements derived from title I of the Act, the purpose of title V is to ensure that the terms and conditions of the preconstruction permit are properly included as “applicable requirements,” and that the permit contains monitoring, recordkeeping, and reporting sufficient to assure compliance with those permit terms and conditions. 
                        <E T="03">See</E>
                         42 U.S.C. 7661c(a), (c); 40 CFR 70.6(a)(1), (a)(3), 70.6(c)(1).
                    </P>
                    <HD SOURCE="HD3">3. Structure of the CAA as a Whole</HD>
                    <P>
                        The EPA's interpretation of “applicable requirements” as that term relates to the interface of title I and title V permits is supported by the structure of the CAA as a whole. 
                        <E T="03">See Utility Air Reg. Group</E>
                         v. 
                        <E T="03">EPA,</E>
                         573 U.S. 302, 320 (2014) (acknowledging the “fundamental canon of statutory construction that the words of a statute must be read in their context and with a view to their place in the overall statutory scheme” (internal citations and quotation marks omitted)). Specifically, the EPA's interpretation is consistent with the title I permitting mechanisms that Congress provided to establish and define the NSR-related requirements of SIPs; the title I and title III procedures for evaluating, challenging, and enforcing title I permitting requirements; and the overarching system of cooperative federalism reflected in the NSR and title V permitting programs.
                        <PRTPAGE P="1178"/>
                    </P>
                    <HD SOURCE="HD3">a. Implementation of SIP Requirements Through Title I NSR Permits</HD>
                    <P>
                        States must submit SIPs containing NSR permitting programs to EPA for approval. 42 U.S.C. 7410(a)(2)(C).
                        <SU>134</SU>
                        <FTREF/>
                         States then determine and define the specific NSR-related requirements of SIPs that apply to individual construction projects by issuing NSR permits to individual facilities. This two-step process under title I is central to the EPA's interpretation of the statutory term “applicable requirements” as it relates to the interface between title I and title V permits. It also differentiates NSR-based applicable requirements from other types of applicable requirements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>134</SU>
                             This section primarily discusses the issuance of NSR permits under an EPA-approved SIP. Similar principles apply to the issuance of NSR permits under an EPA-promulgated FIP.
                        </P>
                    </FTNT>
                    <P>
                        Section III. of this preamble discusses how different types of “applicable requirements” are implemented to greater or lesser extents through title V permitting. In summary, some applicable requirements are self-implementing, in that the specific emission limitations or standards applicable to an individual source (or entire source category) are expressly identified within in the underlying regulation (
                        <E T="03">e.g.,</E>
                         a SIP, FIP, NSPS, or NESHAP regulation). These types of self-implementing requirements are incorporated into title V permits without further review, other than to ensure that the title V permit contains sufficient conditions to assure compliance with those requirements. By contrast, other CAA-based requirements may be written in more general terms, requiring additional steps to define the specific requirements that are applicable to a given facility. In some situations—such as where the underlying regulation contains no direction about the mechanism that must be used to further define such requirements—those requirements may be defined through the title V permitting process. NSR requirements are unique, as they fall between these two examples.
                    </P>
                    <P>The portions of a SIP addressing NSR are general in nature. SIPs require new and modified sources to obtain certain permits before beginning construction; SIPs specify thresholds and other methods to determine what type of permit a source must obtain; SIPs identify other preconditions to obtaining a permit (including requirements related to the NAAQS); and SIPs establish guidelines for establishing specific limitations and other conditions that must be included in a permit. Because the NSR-related provisions within a SIP are necessarily general, they are not self-implementing, and further fact-specific analysis is required to develop the specific requirements applicable to a particular new or modified source.</P>
                    <P>
                        The question then becomes: is title V the appropriate mechanism to establish (or revisit) the specific NSR-related SIP requirements that are applicable to construction activities at a particular source? As noted earlier, title V of the CAA does not mandate this outcome. And the structure of title I makes clear that this was not Congress's intent. Congress required in title I that SIPs regulate construction and require preconstruction permits. 
                        <E T="03">See, e.g.,</E>
                         42 U.S.C. 7475(a)(1), 7502(c)(5); 
                        <E T="03">see</E>
                         42 U.S.C. 7410(a)(2)(C).
                        <SU>135</SU>
                        <FTREF/>
                         It thus follows that the preconstruction permitting requirements for individual sources are established under these programs in the SIP, not through title V. The SIPs identify the title I permitting process as the mechanism by which the more general SIP requirements applicable to construction of stationary sources will be defined for each new or modified source. During that title I permitting process, a permitting authority determines which NSR-related requirements of the SIP are applicable and designs specific permit terms and conditions to satisfy these more general SIP requirements. This process also includes the opportunity for the public to evaluate and challenge the state's decisions. Overall, the process is designed to result in an NSR permit that contains all terms and conditions necessary to satisfy the NSR-related requirements of the SIP. Thus, it is the title I permitting process—not the general requirements within the SIP itself—that defines the “applicable requirements” of the CAA related to NSR, at least insofar as title V is concerned.
                    </P>
                    <FTNT>
                        <P>
                            <SU>135</SU>
                             Although Congress did not specifically require that the minor NSR program be implemented through permitting, nearly all SIPs across the nation implement minor NSR through permitting. This distinction is not relevant to the approach proposed in this rule, because if a source does not obtain a title I permit to authorize construction, then there would be no permit to establish the “applicable requirements” for title V purposes, and the EPA 
                            <E T="03">would</E>
                             review whether the title V permit assures compliance with the relevant requirements of the SIP. See section IV.B.5. of this preamble for further discussion.
                        </P>
                    </FTNT>
                    <P>In summary, the NSR requirements of a SIP are not self-implementing, but they also do not depend on the title V process to be defined. Instead, the applicable NSR-related requirements of SIPs are established through a dedicated title I-based mechanism with its own public participation opportunities and EPA oversight authority: the NSR permitting process.</P>
                    <P>
                        The CAA requires that title V permits assure compliance with “requirements of an applicable [SIP].” But the CAA does not specify that title V be used to re-create or re-evaluate the requirements of the SIP 
                        <E T="03">that were already defined through the specific mechanism Congress designed to define them: the NSR permitting process.</E>
                         Again, the purpose of title V is not to create or alter the substantive requirements from other parts of the CAA, but instead to identify, consolidate, and assure compliance with those requirements established in these other programs that apply to each individual source.
                    </P>
                    <HD SOURCE="HD3">b. Oversight of Title I Programs and Permitting Decisions</HD>
                    <P>
                        The many programmatic and case-specific oversight tools contained within title I demonstrate that it is not necessary—and Congress did not intend—to use additional title V permit oversight tools to second-guess the results of title I permitting decisions.
                        <SU>136</SU>
                        <FTREF/>
                         As introduced in section IV.C.2. of this preamble, title I provides opportunities for programmatic oversight, oversight over individual permitting decisions, and oversight through enforcement.
                    </P>
                    <FTNT>
                        <P>
                            <SU>136</SU>
                             As stated in section IV.C. of this preamble, the EPA's view that reevaluation of NSR permits is not appropriate in the title V permitting context does not mean that the EPA agrees that the state reached the proper decision when setting terms and conditions of such an NSR permit, nor does it diminish the opportunities to review NSR preconstruction permitting decisions under title I of the CAA. 
                            <E T="03">See Env't Integrity Project,</E>
                             960 F.3d at 253.
                        </P>
                    </FTNT>
                    <P>
                        Through the review of SIP submissions, the EPA ensures that states have programs in place that provide the authority to issue substantively sound preconstruction permits, while respecting Congress's intended role for the states. Congress gave the EPA authority under title I to disapprove any proposed SIPs that are inconsistent with federal statutory and regulatory authorities governing NSR. 42 U.S.C. 7410(k). For example, if a state submits a proposed SIP containing rules to calculate major source emissions thresholds, and those rules are inconsistent with the CAA or its implementing regulations, the EPA cannot approve the SIP. 
                        <E T="03">Id.</E>
                         If the state's program subsequently fails to meet statutory or regulatory requirements related to NSR, the EPA can call for a revision of the SIP. 42 U.S.C. 7410(k)(5). Further, if a state fails to properly implement its NSR program, the EPA can take additional actions, including orders, administrative penalties, and civil actions. 42 U.S.C. 7413(a)(2), (5). 
                        <PRTPAGE P="1179"/>
                        The availability of these title I-based authorities obviates the need to use title V-based oversight tools to address programmatic issues associated with state NSR programs.
                    </P>
                    <P>
                        In terms of reviewing individual title I permits, each SIP must provide for public notice and an opportunity for comment on proposed NSR permits in its preconstruction permit program. 42 U.S.C. 7475(a)(2); 40 CFR 51.161; 51.165(i), 51.166(q). The EPA may provide feedback on state-issued NSR permits through this process.
                        <SU>137</SU>
                        <FTREF/>
                         Thus, both the public and the EPA can seek to correct potential errors in proposed preconstruction permits, including threshold determinations about whether a source or modification is minor or major, and can also challenge the content of permit terms. Should a state permitting authority fail to address legitimate comments, either the public or the EPA can seek review of preconstruction permits in state administrative and judicial forums.
                        <SU>138</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>137</SU>
                             
                            <E T="03">See supra</E>
                             note 113 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>138</SU>
                             
                            <E T="03">See supra</E>
                             note 114 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        Congress also provided the EPA and the public with various enforcement mechanisms to address title I permitting issues on a facility-by-facility basis. The EPA possesses the authority to issue injunctive orders to halt construction. 42 U.S.C. 7413(a)(5)(A), 7477. The EPA may also pursue various types of civil or criminal enforcement actions pursuant to sections 113 and 167 of the Act. 42 U.S.C. 7413, 7477. In title III of the CAA, Congress also provided authority for citizens to bring enforcement actions seeking civil penalties and injunctive relief against a source that has violated certain NSR requirements. 42 U.S.C. 7604(a)(1), (a)(3). The enforcement-based tools available to the EPA and members of the public can be used to ensure that decisions made in establishing the terms of a major NSR permit, such as BACT limits, were made on reasonable grounds properly supported by the record. 
                        <E T="03">See, e.g., Alaska Dep't of Env't Conservation</E>
                         v. 
                        <E T="03">EPA,</E>
                         540 U.S. 461 (2004). Additionally, they can be used to address situations where a source failed to obtain a required major NSR permit (even where it obtained a minor source permit). 
                        <E T="03">See, e.g., U.S.</E>
                         v. 
                        <E T="03">S. Ind. Gas &amp; Elec. Co.,</E>
                         No. IP99-1692-CM/F, 2002 WL 1760699, at *3-5 (S.D. Ind. July 26, 2002); 
                        <E T="03">United States</E>
                         v. 
                        <E T="03">Ford Motor Co.,</E>
                         736 F. Supp. 1539, 1550 (W.D. Mo. 1990). These powerful enforcement tools enable the EPA and the public to directly correct the behavior of facilities that pursue illegal construction.
                    </P>
                    <P>Overall, the availability of title I oversight tools weighs against using title V oversight tools to address alleged defects with NSR permitting decisions. As the Fifth Circuit explained:</P>
                    <EXTRACT>
                        <P>EPA contrasts Title V's silence on this front with more stringent oversight authority provided in Title I, arguing that this supports reading the title V provision to supply a more limited oversight role for the EPA with regard to state implementation of preconstruction permitting programs. The agency explains that Title I is better geared for in-depth oversight of case-specific state permitting decisions such as through the state appeal process or an order or action under section[ ] 113 or section 167. And, the agency urges, the absence of such schemes in Title V shows Congress did not intend to recapitulate the Title I process in Title V. We find this reasoning persuasive.</P>
                    </EXTRACT>
                    <FP>
                        <E T="03">Env't Integrity Project,</E>
                         960 F.3d at 249 (internal quotations and citations omitted)). Further, these title I-based oversight tools are more effective than the more limited title V oversight tools. See section IV.E.4.b. of this preamble for further discussion of the practical considerations and other policy reasons why title V oversight tools are not well-suited to resolving complex NSR permitting issues.
                    </FP>
                    <HD SOURCE="HD3">c. Cooperative Federalism and Congressional Intent</HD>
                    <P>
                        Congress, the EPA, and the courts have often described the CAA (like many other environmental statutes) as a program of cooperative federalism. 
                        <E T="03">See, e.g.,</E>
                         42 U.S.C. 7401(a)(3)-(4); 
                        <E T="03">Env't Integrity Project,</E>
                         960 F.3d at 252. The EPA and the states work together to realize the goals of the CAA, but they have different roles. States have the “primary responsibility” for developing SIPs, 42 U.S.C. 7407, as well as issuing title I permits under SIP programs.
                    </P>
                    <P>
                        There is no indication that, in enacting title V, Congress intended to change the balance of state responsibility and federal oversight of title I permitting programs.
                        <SU>139</SU>
                        <FTREF/>
                         To the contrary, the fact that Congress specifically provided a title I-based mechanism to establish the applicable NSR-related requirements, as well as title I- and title III-based tools for the EPA and citizens to oversee this program, weighs against using title V to re-evaluate, re-establish, or otherwise oversee those title I requirements. Congress “does not alter the fundamental details of a regulatory scheme in vague terms or ancillary provisions—it does not, one might say, hide elephants in mouseholes.” 
                        <E T="03">Whitman</E>
                         v. 
                        <E T="03">Am. Trucking Ass'ns,</E>
                         531 U.S. 457, 468 (2001). A reading of title V that would transform it into an opportunity to reevaluate previous preconstruction approvals, instead of simply incorporating existing air pollution requirements into one document, would inappropriately “alter the fundamental details” of the oversight authorities the EPA has under title I of the Act.
                    </P>
                    <FTNT>
                        <P>
                            <SU>139</SU>
                             In fact, as noted in section IV.E.2. of this preamble, the legislative history surrounding the 1990 CAA Amendments suggests that Congress did not intend for the title V program to change the implementation of title I permits.
                        </P>
                    </FTNT>
                    <P>
                        The text of the Act does not indicate that Congress intended to create this type of additional administrative oversight mechanism for preconstruction permitting actions in an operating permit program designed to consolidate and make existing requirements enforceable. While there is language in title V requiring that a permit “assure compliance with applicable requirements of this chapter,” 
                        <E T="03">e.g.,</E>
                         42 U.S.C. 7661c(a), and similarly broad language in other parts of title V, this type of general language does not clearly or specifically say that a title V permitting authority must reevaluate preconstruction permitting decisions that have already been made under title I each time that it issues or renews a title V permit. Instead, this general language in the statute should be read to mean that the title V permit must include conditions to assure compliance with the terms and conditions of the source-specific preconstruction permits.
                    </P>
                    <P>In summary, as the Fifth Circuit concluded in its close examination of Title V:</P>
                    <EXTRACT>
                        <P>Beyond the structure of Title V, EPA also persuasively grounds its interpretation in the structure of the Act as a whole. According to EPA, when Congress added preconstruction permitting requirements to Title I in 1977, it understood that the adequacy of state preconstruction permitting decisions would be subject to review in state administrative and judicial forums. It gave EPA oversight authority over preconstruction permitting only in specific ways, to do specific things. For example, Congress delineated the processes EPA must go through to approve SIPs. When it enacted Title V thirteen years later, Congress granted EPA no such authority. Congress gave no clear indication that it intended to alter the balance of oversight EPA has over state permitting processes. Section 7661c(a)'s requirement that a Title V permit assure compliance with applicable requirements is general and broad and does not clearly or specifically require the revisiting of preconstruction permitting decisions. Once again, the elephants in mouseholes canon supports this reading.</P>
                    </EXTRACT>
                    <FP>
                        <E T="03">Env't Integrity Project,</E>
                         960 F.3d at 252 (cleaned up).
                        <PRTPAGE P="1180"/>
                    </FP>
                    <HD SOURCE="HD3">4. Policy Reasons</HD>
                    <P>In addition to the textual and legal interpretations supporting this action, several policy considerations also support this proposed rule. The EPA's current (and proposed) approach: ensures that applicable requirements established in different CAA programs are treated consistently in title V permitting; better accounts for procedural, resource-based, and practical limitations associated with title V oversight tools; incentivizes the use of proper title I avenues of review; and respects the finality of NSR permitting decisions.</P>
                    <HD SOURCE="HD3">a. Consistent Treatment of Applicable Requirements From Other CAA Programs</HD>
                    <P>The EPA's current (and proposed) approach aligns the EPA's treatment of preconstruction permits with how the EPA has consistently treated other “applicable requirements” under title V. As detailed in section III.E. of this preamble, for many other applicable requirements, permitting authorities do not reconsider the content of those requirements in title V permits, nor does the EPA in its oversight role of title V permitting. For instance, the EPA would not allow a permitting authority to revise the self-implementing substantive requirements of an NSPS established under CAA section 111 or a NESHAP established under CAA section 112. Similarly, it would not be appropriate for the EPA to review or revise any self-implementing requirements of a SIP approved under CAA section 110. In fact, as explained in Section III.G of this preamble, even if the EPA disagrees with the content of a SIP, until the EPA approves a corrective SIP revision or issues a FIP, the SIP requirement remains an “applicable requirement” that should be incorporated unchanged into the title V permit.</P>
                    <P>For purposes of establishing “applicable requirements” for title V permitting, it is logical and appropriate to treat decisions that go through similar processes similarly. Each of the applicable requirements addressed in the previous paragraph were established pursuant to a process that included public notice and the opportunity for comment and judicial review. Once they are established following these procedures, it would be inappropriate to reevaluate the substance of these requirements in title V permitting. Likewise, most source-specific NSR permitting decisions must go through a similar process at the state level. Once established through the appropriate procedures, and unless and until the terms and conditions of an NSR permit are revised, reopened, suspended, revoked, reissued, terminated, augmented, or invalidated through some other mechanism (such as a state court appeal or enforcement action), the “applicable requirements” remain the terms and conditions of the issued NSR permit. These requirements should be incorporated into the title V permit without further review, just like all other similarly established applicable requirements.</P>
                    <P>
                        Any differences between NSR-based applicable requirements and other types of applicable requirements do not provide a convincing reason to treat NSR requirements differently. For example, the fact that NSR permits are reviewed through the state courts, as opposed to federal courts, is not material. As discussed in section IV.B.2. of this preamble, regardless of the jurisdiction involved, both processes are functionally similar and offer similar levels of public involvement and measured decisionmaking.
                        <SU>140</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>140</SU>
                             To the extent federal court review of NSR decisions offers independent value beyond that which may be achieved through state courts, the CAA specifically provides for various means by which the EPA or the public can raise NSR issues to federal courts. See sections IV.C.2. and IV.E.3.b. of this preamble for additional information.
                        </P>
                    </FTNT>
                    <P>Additionally, as discussed in section IV.E.3.a. of this preamble, the NSR-related requirements of the SIP are often general and would not be described as “self-implementing” in the same manner as NSPS, NESHAP, or certain source-specific SIP requirements. However, after a source goes through the preconstruction permitting process and emerges with a final NSR permit, the terms of that NSR permit are legally effective in the same manner as any NSPS, NESHAP, or source-specific SIP provision. That is, those NSR permit terms are immediately applicable and enforceable and require no further substantive refinement through, for example, title V permitting.</P>
                    <P>
                        The EPA's current (and proposed) approach also standardizes the EPA's treatment of questions related to the applicability of different types of CAA requirements. Identifying which requirements apply to a source (
                        <E T="03">i.e.,</E>
                         which requirements must be included in the title V permit) is a key function of the title V permitting process. However, it is only necessary and appropriate to use title V to substantively address questions regarding applicability when such questions have not already been resolved by the underlying applicable requirement itself and when such questions require further site-specific factual analysis. For example, it would be appropriate to use the title V permitting process to determine whether—or which specific requirements within—a generally applicable NSPS, NESHAP, or SIP requirement applies to a particular source or piece of equipment, provided such a decision was not reflected in some other final action. Likewise, title V could be used to address whether a source should have obtained either a minor or major NSR permit where such a decision had not already been made following the appropriate title I permitting process.
                    </P>
                    <P>
                        By contrast, if the applicability of a SIP requirement is established on the face of the SIP itself (
                        <E T="03">e.g.,</E>
                         in a source-specific SIP provision), the EPA would not re-evaluate this question through title V. Or, if the EPA has already issued a formal determination regarding the applicability of an NSPS or NESHAP standard, the EPA would not re-evaluate the same issues through title V.
                        <SU>141</SU>
                        <FTREF/>
                         Provided a minor NSR permit has been issued following sufficient procedures, major NSR applicability questions are similar to the latter two examples. That is, where an NSR applicability determination has already been made through the title I process—where a state decides that major NSR does not apply to new or modified source and therefore issues a minor NSR permit—that applicability determination establishes the relevant requirements of the SIP that are applicable to the source or project. Any further action by EPA through title V would involve reconsidering that final title I action relevant to applicability. Moreover, if EPA were to conclude that major NSR requirements were applicable (as opposed to minor NSR requirements), such a determination would effectively require revising the substantive applicable requirements established in the final minor NSR permit (since major NSR requirements are generally more stringent than minor NSR requirements). Neither of these outcomes are consistent with how the EPA treats applicable requirements and applicability determinations under other CAA programs. Accordingly, the EPA considers it better policy to afford NSR applicability decisions the same finality as applicability decisions under other CAA programs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>141</SU>
                             
                            <E T="03">See supra</E>
                             note 32 and accompanying text.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Procedural, Resource-Based, and Other Practical Limitations of Title V Oversight Tools</HD>
                    <P>
                        In the EPA's experience, NSR permitting issues are among the most 
                        <PRTPAGE P="1181"/>
                        factually and legally complicated issues raised during the title V permitting (and petition) process. For multiple reasons, the oversight tools associated with title V permitting process are a poor fit for resolving NSR permitting issues. Compared to the available title I avenues for review, the title V process features limited timelines and procedural opportunities to fully evaluate complex title I issues. Reviewing complex NSR issues through title V involves a considerable resource burden and often is impracticable for decisions made years ago. Even where title V can be used to review NSR issues, the EPA's authority to resolve such issues is indirect, at best.
                    </P>
                    <P>Procedural constraints associated with title V oversight tools weigh against using these tools to resolve complex NSR issues. Congress provided the EPA with only 45 days to review proposed title V permits, followed by a 60-day period for the public to petition the EPA to object, followed by a 60-day period for the EPA to rule on a petition to object. 42 U.S.C. 7661d(b)(1)-(2). These brief title V review periods are inconsistent with an in-depth and searching review of potentially every source-specific preconstruction permitting decision that has been made by the permitting authority. By contrast, available title I review mechanisms—state court appeals and enforcement actions—are not subject to the same time constraints and allow more time for development and consideration of NSR permitting decisions.</P>
                    <P>
                        In addition to time constraints, the title V permitting and petition processes involve fewer opportunities to develop the factual record necessary for a complete review of complex NSR permitting issues. For example, by the time the EPA receives a title V petition, the EPA's review is generally limited to the record developed by the permitting authority up to that point. 
                        <E T="03">See</E>
                         40 CFR 70.13. By contrast, some state permit appeal and enforcement processes provide more in-depth oversight than title V could afford. Some states have administrative appeal processes that enable additional factual development before a final decision is reached on the permit. In addition, “unlike the permitting process, the enforcement process allows for discovery, hearings, cross-examination of witnesses, and expert testimony,” all of which aid the fact-finder in deciding whether major or minor source preconstruction requirements apply to a facility, or whether such requirements were correctly established. 
                        <E T="03">Citizens Against Ruining the Envt.</E>
                         v. 
                        <E T="03">EPA,</E>
                         535 F.3d 670, 678 (7th Cir. 2008).
                    </P>
                    <P>
                        Moreover, once a title V petition is filed, there are no formal opportunities for other affected parties, such as the permitted source or the state permitting authority, to directly participate in the review process; their opportunity to develop their position occurs earlier in the permitting process. 
                        <E T="03">See</E>
                         85 FR 6431, 6442 (February 5, 2020). These other affected stakeholders have more procedural safeguards in state appeal processes and enforcement actions than in the title V petition process. For example, they may be parties to the action and appear before neutral arbiters, and have the opportunity to contest points raised by public challengers through briefs or other filings. Overall, title V oversight processes contain fewer mechanisms than title I oversight processes to fully consider and resolve complex NSR issues.
                        <SU>142</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>142</SU>
                             
                            <E T="03">See Env't Integrity Project,</E>
                             960 F.3d at 253 (“We are persuaded by the agency's contrasting Title V against Title I's more detailed procedures for in-depth oversight of case-specific permitting decisions. Such permitting decisions follow state appeals or enforcement actions authorized by other provisions of the Act, including citizen suits under Title III. Those mechanisms are better structured to provide agency and citizen oversight of preconstruction permitting. . . . Title V contains none of the procedures that would guide those challenges, as Titles I and III do. . . . And those avenues provide more time for development and consideration of the potential issues.” (internal citations and quotations omitted)).
                        </P>
                    </FTNT>
                    <P>
                        Title V's limited effectiveness in addressing NSR issues is compounded by the fact that title V permits must be renewed every 5 years. This fact, along with the EPA's longstanding position that all aspects of a title V permit are subject to review during renewal permit proceedings,
                        <SU>143</SU>
                        <FTREF/>
                         gives rise to the possibility that, in the absence of the EPA's current (and proposed) approach, the public will seek to use title V oversight tools to review long-past NSR permit decisions. For example, in the 2016 
                        <E T="03">PacifiCorp-Hunter I</E>
                         petition that precipitated the EPA's current interpretation, public interest groups challenged an NSR applicability decision made nearly 20 years prior. Given state and federal record retention schedules, staff turnover at state permitting authorities, and similar practical constraints associated with the passage of time, it may simply be impossible in a title V permitting action for a state to recreate a complete, defensible administrative record to support complex, substantive NSR permitting decisions, particularly those made long ago. Instead of pursuing challenges to NSR permitting decisions when a state incorporates a preconstruction permit into a title V permit, or during subsequent title V renewals, interested parties can obtain more direct and timely relief through state permit appeals and enforcement actions at the tile a title I permit is issued.
                    </P>
                    <FTNT>
                        <P>
                            <SU>143</SU>
                             
                            <E T="03">See, e.g., In the Matter of Wisconsin Public Service Corporation, Weston Generating Station,</E>
                             Order on Petition No. V-2006-4 at 5-7 (December 19, 2007).
                        </P>
                    </FTNT>
                    <P>
                        Some of the constraints on the EPA's and state's ability to address NSR issues through title V may be mitigated by the fact that Congress placed the burden on 
                        <E T="03">petitioners</E>
                         to demonstrate to the EPA's satisfaction that a title V permit does not satisfy the CAA. In other words, in the situations where NSR issues are properly within the scope of the EPA's title V review, the EPA is not required to undertake an exhaustive independent review of a state's NSR decisions. Instead, petitioners are required to provide sufficient evidence to EPA to demonstrate that the state's NSR permitting decisions did not comply with its SIP-approved regulations or that the state's exercise of discretion under such regulations was unreasonable or arbitrary.
                        <SU>144</SU>
                        <FTREF/>
                         Although this demonstration requirement reduces some of the EPA's resource burdens, it places these burdens on the public, who are subject to similarly tight timelines and the other procedural limitations discussed in the preceding paragraphs. As a result of these constraints, combined with the complexity of NSR permitting decisions, it has historically been relatively uncommon for petitioners to successfully demonstrate that an NSR-related deficiency warrants the EPA's objection to a title V permit. As discussed throughout this preamble, the EPA believes the public would be better served to develop any challenges to NSR permitting decisions using title I avenues.
                    </P>
                    <FTNT>
                        <P>
                            <SU>144</SU>
                             
                            <E T="03">See, e.g., Appleton Order</E>
                             at 5.
                        </P>
                    </FTNT>
                    <P>
                        Title V mechanisms are poorly suited not only for 
                        <E T="03">considering</E>
                         NSR-related issues, but also for 
                        <E T="03">resolving</E>
                         NSR-related issues. The relief that the EPA can provide through title V to correct an NSR deficiency is limited and indirect. When the EPA objects to a title V permit on the grounds that NSR requirements were not properly established by a state, such objection does not directly invalidate an NSR permit or stop the initial construction or operation of a particular source authorized by an NSR permit. This is true not only when the NSR permit was issued long ago and construction has already been completed,
                        <SU>145</SU>
                        <FTREF/>
                         but also when the NSR 
                        <PRTPAGE P="1182"/>
                        permit was issued more recently and construction has not yet begun. An EPA objection similarly cannot directly require the state to amend an NSR permit. Instead, the EPA's authority to object to a title V permit reaches only the terms of the title V permit itself. For example, the EPA could direct a state to include a compliance schedule in the title V permit directing the source to apply for a new NSR permit. Resolving such an objection would generally require some type of additional, and legally distinct, NSR permitting action by the state permitting authority. If the state ultimately failed to update the title V permit in a manner sufficient to resolve the EPA's objection, then the EPA could then assume responsibility to issue the title V permit. 42 U.S.C. 7661d(c).
                        <SU>146</SU>
                        <FTREF/>
                         But even so, the EPA would remain unable to directly change the terms of the underlying NSR permit, or to issue a new NSR permit to the source, without first pursuing title I-based oversight authorities.
                        <SU>147</SU>
                        <FTREF/>
                         Thus, no matter what the EPA might do with respect to a title V permit, the EPA lacks title V-based authority to directly intercede and fix issues in NSR permits. Thus, even in cases where the EPA entertained NSR-related claims in title V petitions, the resulting orders rarely resulted in a change to the NSR permit or additional NSR requirements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>145</SU>
                             As explained previously, the EPA's regulations allow sources subject to major NSR 
                            <PRTPAGE/>
                            preconstruction permitting requirements to apply for a title V permit within 1 year after beginning operation (well after beginning and completing construction), in most cases. 40 CFR 70.5(a)(1)(ii); 71.5(a)(1)(ii). The CAA similarly allows sources to apply for a title V permit up to 12 months 
                            <E T="03">after</E>
                             becoming subject to title V. 42 U.S.C. 7661b(c). This shows that Congress did not intend for the title V permitting process to be used to prevent the construction of a source authorized under title I.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>146</SU>
                             The EPA could also assume responsibility to issue title V permits within a jurisdiction after determining, for example, that the state failed to properly administer and enforce its title V program. 
                            <E T="03">See</E>
                             42 U.S.C. 7661a(i)(4); 40 CFR 70.10(b)(4), (c), 71.4(c).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>147</SU>
                             To directly mandate changes to an NSR permit issued by a state under an EPA-approved SIP, the EPA would need to pursue title I remedies. For example, a court order following a state court appeal, or an enforcement action, could directly mandate that the state permitting authority revise specific NSR permit terms or issue a different type of NSR permit. Alternatively, if the EPA wanted to directly issue an NSR permit to a source that was previously subject to a state permitting authority's jurisdiction, the EPA would first have to issue a “SIP Call” under CAA section 110(k) and ultimately impose a FIP, after which the EPA would retake the legal authority to issue NSR permits.
                        </P>
                    </FTNT>
                    <P>Given that the title V oversight tools provide an ill-suited forum for considering and resolving the complex problems associated with NSR permitting, it makes sense that title V permitting authorities and the EPA should only consider whether the terms and conditions of an NSR permit have been properly included in a title V operating permit, and whether there is sufficient monitoring, recordkeeping, and reporting to assure compliance with those terms and conditions. It is more efficient for state permitting authorities, the public, and the EPA to focus on these core title V issues—which are more clearly redressable through title V oversight tools—when preparing title V permits, challenging title V permits, and reviewing title V permits.</P>
                    <HD SOURCE="HD3">c. Incentivizing Title I Avenues of Review</HD>
                    <P>The EPA's current (and proposed) approach not only recognizes the limitations on using title V to review NSR issues, but also emphasizes the importance of public involvement in the title I permitting process to address these issues. This approach encourages the public to engage contemporaneously at the state level to appeal preconstruction permitting decisions that they believe to be incorrect.</P>
                    <P>
                        As explained in the preceding subsection, the title I permitting process (and other oversight opportunities under titles I and III of the CAA) is better suited to addressing public concerns than the title V permitting process. From a policy standpoint, the EPA's view that the title V permitting process should not be used to reconsider final NSR permitting decisions relies heavily on the opportunity for the public to participate in the title I permitting process. The proposed revisions to the EPA's regulations include criteria relevant to public participation in the title I permitting process. Provided these criteria are satisfied in the issuance of a title I permit, NSR-related decisions associated with that permit would not be subject to further review through title V. The EPA expects that codifying this existing framework will create a strong incentive for state permitting authorities to ensure meaningful public access to NSR permitting actions, particularly for minor NSR permitting actions that may have limited public participation opportunities.
                        <SU>148</SU>
                        <FTREF/>
                         This rulemaking is expected to complement related ongoing efforts by the EPA to promote increased implementation of existing requirements related to public participation in minor NSR permit actions.
                    </P>
                    <FTNT>
                        <P>
                            <SU>148</SU>
                             Similarly, the EPA expects that permittees will have an incentive to request that state permitting authorities provide such opportunities for the public to participate in the title I permitting process, so as to avoid the potential that title I permitting decisions will be subsequently overturned using the EPA's title V review authorities.
                        </P>
                    </FTNT>
                    <P>
                        This approach not only creates an incentive for states to offer more opportunities for public access in NSR permitting, but also for the public to use such processes. During the time period in which the EPA nominally considered the merits of NSR issues through the title V permitting and petition process, the EPA observed that many petitioners would 
                        <E T="03">only</E>
                         raise their NSR-related concerns through the title V process and would not seek relief through title I mechanisms. By doing this, citizens bypassed an available public participation opportunity and denied the state an opportunity to hear and remedy public concerns contemporaneous with the state action. Moreover, given the inherent difficulty in demonstrating NSR permit flaws and the lack of effective relief available through the title V permitting process, use of title V (rather than NSR appeal processes) may have ultimately been less effective at fostering sound NSR permitting decisions. The EPA believes it is better policy to encourage the public to use title I venues to address NSR-related concerns at the time these permits are issued, and to reserve the title V permitting process for issues that may be more effectively addressed through title V authorities (
                        <E T="03">e.g.,</E>
                         monitoring).
                        <SU>149</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>149</SU>
                             Of course, as explained in section IV.B.5.a. of this preamble, where the public is denied meaningful opportunities to participate in title I permitting decisions, title V will serve as a backstop to ensure that the public has an opportunity to ensure that a source's title V permit assures compliance with the relevant NSR-related requirements.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">d. Respecting Finality and Fostering Certainty in Title I Permitting Decisions</HD>
                    <P>Declining to review title I permitting decisions in title V review avoids duplication and inefficiency, respects the finality of NSR permitting decisions that are subject to public notice and the opportunity for comment and judicial review, and acknowledges regulated entities' need for certainty when investing in the construction and modification of sources.</P>
                    <P>
                        The availability of public notice, the opportunity for comment, and the opportunity for judicial review of underlying NSR permit actions weigh heavily against the need to repeat all these procedures through title V permitting. This allows an unnecessary and inefficient “second bite at the apple,” along with a potentially unlimited number of additional “bites” each time a title V permit is reviewed.
                        <PRTPAGE P="1183"/>
                    </P>
                    <P>
                        The EPA's current (and proposed) approach respects the finality of a permitting authority's title I permitting decisions, provided such decisions were made with the requisite level of formality, consideration, and public process (
                        <E T="03">i.e.,</E>
                         issued under title I authorities following public notice and the opportunity for comment and judicial review). By contrast, allowing NSR permitting decisions to be collaterally attacked using the title V permitting process would significantly undermine the finality of state title I permitting decisions. This would decrease the relative importance of states in the cooperative federalist system established by Congress.
                    </P>
                    <P>
                        The EPA believes that the best policy (and best reading of the Act as a whole, as described in section IV.E.3. of this preamble) is that the public should directly participate in state preconstruction permitting decisions and, if necessary, seek review in state court immediately thereafter. This is a more direct and timely way to identify and correct errors in preconstruction permits. It provides for such review before sources reasonably begin relying on those permits to invest substantial resources in a facility. Thus, the EPA's current (and proposed) approach fosters certainty and avoids upsetting settled expectations and reliance interests of sources that have obtained a legally enforceable preconstruction permit under title I. By contrast, under the EPA's former approach, stakeholders would always face the possibility that the EPA could identify errors with the state preconstruction permitting decisions during title V permit issuance or renewal. In such a circumstance, discovery of errors could come years after the fact, long after a source is constructed and operating, either when a title V permit first incorporates the relevant NSR requirements, or decades after the fact, when the title V permits is subsequently renewed.
                        <SU>150</SU>
                        <FTREF/>
                         This would increase uncertainty for the regulated community. It would also increase the burden on EPA, state agencies, and the courts to consider such long-distant issues. As summarized by the Fifth Circuit in examining EPA's current approach:
                    </P>
                    <FTNT>
                        <P>
                            <SU>150</SU>
                             See section IV.B.4. of this preamble for additional information about the timing of NSR and title V permit actions.
                        </P>
                    </FTNT>
                    <EXTRACT>
                        <P>EPA's position also respects the finality of the preconstruction permitting decision. The agency reasoned that it would be inefficient to allow review via the Title V permitting process even after the preconstruction permits had been subject to public notice and comment and an opportunity for judicial review. And those avenues provide more time for development and consideration of the potential issues. We are persuaded that EPA's construction of Title V respects the finality of state preconstruction permitting decisions, which is consistent with the Act's cooperative federalism. Petitioners' contrary view of Title V would allow a federal agency to upset states' permitting decisions with no clear mandate from Congress to do so.</P>
                    </EXTRACT>
                    <FP>
                        <E T="03">Env't Integrity Project,</E>
                         960 F.3d at 253 (internal citations and quotations omitted).
                    </FP>
                    <HD SOURCE="HD2">F. Alternative Approaches</HD>
                    <P>The EPA believes that the agency's existing interpretations and policies reflect the best approach from both a legal and policy standpoint, for the reasons discussed previously. Thus, the EPA is proposing to codify its existing approach. However, the EPA also solicits comment on the following alternative approaches that would involve using title V permits to address substantive NSR issues in additional, targeted situations. Each of the alternatives presented features some level of intuitive appeal but also suffers from legal and/or policy drawbacks. Thus, the EPA specifically requests comments that would provide further legal and/or policy support for applying these alternatives as opposed to the EPA's preferred approach. The EPA also specifically requests comments on how such alternatives could be reflected in the regulatory text.</P>
                    <P>As discussed in the following subsections, the alternatives that the EPA is considering include: (i) using title V to review contemporaneous or recent NSR permitting decisions; (ii) using title V to review issues related to major NSR applicability, and (iii) using title V to review contemporaneous or recent NSR permitting decisions related to major NSR applicability.</P>
                    <HD SOURCE="HD3">1. Using Title V To Review Contemporaneous or Recent NSR Permitting Decisions</HD>
                    <P>
                        Under the first alternative approach, the title V permitting process could be used to review contemporaneous or recent NSR permitting decisions, but not older NSR permitting decisions.
                        <SU>151</SU>
                        <FTREF/>
                         Within this alternative, there are multiple potential variations based on the time frame chosen to differentiate between NSR decisions that would, and would not, be reviewed. For example, the narrowest version of this alternative would involve using title V to review NSR-related decisions that are made contemporaneously with the issuance of a title V permit. Broader versions of this alternative would involve reviewing NSR permitting decisions finalized within a certain period of time before a title V permit is issued.
                    </P>
                    <FTNT>
                        <P>
                            <SU>151</SU>
                             This approach is similar to prior EPA statements that the EPA would not review NSR decisions made long ago. 
                            <E T="03">See supra</E>
                             notes 51 and 56 and accompanying text.
                        </P>
                    </FTNT>
                    <P>This alternative approach has some appeal because it avoids some of the practical challenges that motivated, and which support, the EPA's current approach. For example, this alternative would avoid problems associated with the EPA and states being expected to confront long-past NSR decisions without a fully accessible record. This alternative is also less likely to upset settled expectations, particularly if review is restricted to contemporaneously issued NSR and title V permits. However, this alternative would not address other important policy considerations to the same extent as the EPA's proposed approach. For example, this alternative would not address the limited scope and timing available for reviewing complex NSR issues through title V.</P>
                    <P>Additionally, this alternative would give rise to its own set of problems. For example, reviewing NSR decisions based on a defined timing element would involve a difficult line-drawing exercise. Would it be appropriate to review only NSR decisions finalized at the exact same time as a title V permit issuance, or NSR decisions finalized shortly before a title V permit is finalized, or within the same year, or within five or six years, or some other period of time? The EPA solicits comments on how to define this timing element under this alternative.</P>
                    <P>Moreover, to the extent this alternative would be applied narrowly to allow title V review of only contemporaneous NSR permitting decisions, this approach could disincentivize states from taking advantage of streamlined permit issuance procedures (which many states currently employ), such as the concurrent permit issuance process described in section IV.B.4. of this preamble. Disincentivizing streamlined permitting could increase administrative burdens and costs for states and could lead to unnecessary delays in title V permit issuance, counter to the CAA's directive to develop “[a]dequate, streamlined, and reasonable procedures for expeditiously” issuing permits. 42 U.S.C 7661a(b)(6).</P>
                    <P>
                        In addition to these policy considerations, it is not clear what legal basis would support an alternative approach based exclusively on the timing of NSR and title V permit issuance. As discussed extensively 
                        <PRTPAGE P="1184"/>
                        earlier in this preamble, the relationship between NSR and title V permits is closely tied to the concept of “applicable requirements” that are established under other CAA programs. This concept has generally been time-neutral, such that requirements that are properly established under another EPA program—regardless of when they are established—define the applicable requirements that must be included in a title V permit. To the extent the EPA has addressed timing considerations, is has been to ensure that the definition of “applicable requirement” is overinclusive with respect to requirements that have already been promulgated but are not yet effective. 
                        <E T="03">See</E>
                         40 CFR 70.2 (definition of “applicable requirement”). This alternative approach would require the opposite position, 
                        <E T="03">excluding</E>
                         recent NSR permitting decisions from establishing applicable requirements just because they were undertaken more recently. That position would conflict with the EPA's treatment of applicable requirements under all other types of CAA programs. It is not clear to the EPA that such an approach is compatible with the structure and purpose of the title V program.
                    </P>
                    <P>Further information explaining why the EPA does not prefer this alternative is included in section IV.B.4. of this preamble (which explains why the EPA's approach applies the same regardless of when an NSR permit was issued).</P>
                    <HD SOURCE="HD3">2. Using Title V To Review Issues Related to Major NSR Applicability</HD>
                    <P>
                        The second alternative approach under consideration would involve using the title V permitting process to review issues related to major NSR applicability (
                        <E T="03">i.e.,</E>
                         whether a source should have received a major NSR permit instead of a minor NSR permit). However, the EPA would not review challenges to other types of substantive NSR issues (
                        <E T="03">e.g.,</E>
                         BACT determinations or the results of modeling). This alternative would apply the same regardless of the timing of NSR permit issuance and title V permit issuance.
                    </P>
                    <P>
                        This alternative approach would provide some of the same policy benefits as the EPA's proposed approach, in that it would avoid using title V to reevaluate the content of NSR permits (
                        <E T="03">e.g.,</E>
                         whether permit limits correctly reflect BACT). However, given that major NSR applicability questions are among the most complicated NSR-related issues to address, this approach would do little to resolve the resource-related and practical problems that partly motivated the EPA's current (and proposed) approach. For the reasons discussed in section IV.E.4.b. of this preamble, the EPA does not consider the title V permitting process well-suited to resolving these complex questions involving major NSR applicability.
                    </P>
                    <P>
                        One might argue that this alternative approach is consistent with the view that the title V process can be used to determine which requirements are applicable to a source, even if it should not be used to second-guess the content of such requirements.
                        <SU>152</SU>
                        <FTREF/>
                         However, where an NSR applicability determination has already been made through the NSR process and a minor NSR permit is issued, any further action through title V related to major NSR applicability would likely require changes to emissions limits and other applicable requirements established through that NSR process. In other words, using title V to revisit NSR applicability questions would inherently upset not only the NSR applicability decisions, but also NSR permit content decisions. The EPA does not view this result as consistent with the key function of title V.
                    </P>
                    <FTNT>
                        <P>
                            <SU>152</SU>
                             This line of reasoning, based on certain statements made when the EPA promulgated the part 70 rules, featured in the Tenth Circuit's interpretation of the current regulatory definition of “applicable requirement.” 
                            <E T="03">See Sierra Club</E>
                             v. 
                            <E T="03">EPA,</E>
                             964 F.3d at 893-895.
                        </P>
                    </FTNT>
                    <P>Further information explaining why the EPA does not prefer this alternative is included in section IV.B.3. of this preamble (which contains the EPA's justification for applying its approach uniformly regardless of the type of substantive NSR requirements at issue) and section IV.E.4.a. of this preamble (which explains why the EPA's proposed approach is more consistent wih how applicability questions are treated with respect to other CAA programs).</P>
                    <HD SOURCE="HD3">3. Using Title V To Review Contemporaneous or Recent NSR Permitting Decisions Related to Major NSR Applicability</HD>
                    <P>
                        The third and final alternative approach under consideration would involve using title V to review contemporaneous or recent NSR permitting decisions related to major NSR applicability, but not any older NSR decisions or any NSR decisions related to NSR permit content. This approach is a combination of the preceding two alternatives, and is consequently narrower than either two alternatives—that is, it would involve the use of title V to review NSR issues in fewer situations. 
                        <E T="03">See</E>
                         the preceding subsections for considerations relevant to this alternative.
                    </P>
                    <HD SOURCE="HD1">V. The General Duty Clause Concerning the Prevention of Accidental Releases of Hazardous Substances</HD>
                    <HD SOURCE="HD2">A. Background and Summary of Proposed Action</HD>
                    <P>
                        On two occasions in recent years, the EPA received title V petitions requesting that individual title V permits include requirements designed to assure compliance with the “General Duty Clause” of CAA 112(r)(1), which concerns the prevention of accidental releases of hazardous substances. These petitions were premised upon the suggestion that the General Duty Clause is an “applicable requirement” for title V purposes. However, as the EPA explained in the 
                        <E T="03">Hazlehurst</E>
                         and 
                        <E T="03">Owens-Brockway Orders</E>
                         denying both of these petitions, the General Duty Clause is not an applicable requirement for title V.
                        <SU>153</SU>
                        <FTREF/>
                         The basis for this position is fully explained in the EPA's 
                        <E T="03">Hazlehurst</E>
                         and 
                        <E T="03">Owens-Brockway Orders.</E>
                         However, for the sake of transparency, section V.B. of this preamble restates salient points from those orders.
                    </P>
                    <FTNT>
                        <P>
                            <SU>153</SU>
                             
                            <E T="03">In the Matter of Owens-Brockway Glass Container Inc.,</E>
                             Order on Petition No. X-2020-2 at 21-28 (May 10, 2021) (
                            <E T="03">Owens-Brockway Order</E>
                            ); 
                            <E T="03">In the Matter of Hazlehurst Wood Pellets, LLC,</E>
                             Order on Petition No. IV-2020-5 at 7-14 (Dec. 31, 2020) (
                            <E T="03">Hazlehurst Order</E>
                            ).
                        </P>
                    </FTNT>
                    <P>Moreover, although the current definition of “applicable requirement” in the EPA's part 70 and part 71 regulations may reasonably be read to exclude requirements of the General Duty Clause, the EPA intends to provide further clarity to the public by making this exclusion explicit in the EPA's regulations.</P>
                    <P>This proposed change to the rules is not expected to have any impacts on state permitting authorities, regulated entities, the public, or other stakeholders, as it simply clarifies an element of the title V program that has been understood and implemented in the same way since the inception of the title V program in the early 1990s.</P>
                    <P>This proposed change is distinct and severable from the proposed changes related to the interface between title V permits and NSR permits, discussed in section IV. of this preamble.</P>
                    <HD SOURCE="HD2">B. Rationale for Proposed Action</HD>
                    <HD SOURCE="HD3">1. Statutory Provisions</HD>
                    <P>The General Duty Clause provides:</P>
                    <EXTRACT>
                        <P>
                            The owners and operators of stationary sources producing, processing, handling or storing such substances have a general duty in the same manner and to the same extent as section 654 of title 29 to identify hazards which may result from such releases using appropriate hazard assessment techniques, to design and maintain a safe facility taking 
                            <PRTPAGE P="1185"/>
                            such steps as are necessary to prevent releases, and to minimize the consequences of accidental releases which do occur. 
                            <E T="03">For purposes of this paragraph, the provisions of section 7604 of this title shall not be available to any person or otherwise be construed to be applicable to this paragraph.</E>
                        </P>
                    </EXTRACT>
                    <FP>42 U.S.C. 7412(r)(1) (emphasis added). The last sentence contains a key limitation of the General Duty Clause: it means that citizen suits under CAA section 304 shall not be available to enforce the requirements of the General Duty Clause; instead, this clause may only be enforced by the EPA under CAA section 113.</FP>
                    <P>
                        This enforcement prohibition also effectively restricts the implementation of the General Duty Clause requirements through title V permitting. The CAA provides that all standards and limitations in title V permits are enforceable by citizens under section 304.
                        <SU>154</SU>
                        <FTREF/>
                         Thus, if the requirements of the General Duty Clause were included in title V permits, they would ostensibly be enforceable through enforcement of the title V permit itself. However, this would be in direct conflict with the unambiguous statutory prohibition on citizen enforcement of the General Duty Clause under section 304.
                        <SU>155</SU>
                        <FTREF/>
                         To avoid this conflict, the General Duty Clause must not be considered an “applicable requirement” that is implemented through title V permitting.
                    </P>
                    <FTNT>
                        <P>
                            <SU>154</SU>
                             This is because any person may, under CAA section 304(a)(1), bring a suit “against any person . . . who is alleged to have violated . . . or be in violation of (A) an emission standard or limitation under this chapter . . . .” In turn, “emission standard or limitation” is defined to include, 
                            <E T="03">inter alia,</E>
                             “any other standard, limitation, or schedule established under any permit issued pursuant to subchapter V of this chapter . . . .” 42 U.S.C. 7604(f)(4); 
                            <E T="03">see also</E>
                             40 CFR 70.6(b)(1); 
                            <E T="03">see United States</E>
                             v. 
                            <E T="03">Gonzales,</E>
                             520 U.S. 1, 5 (1997). As discussed later, the EPA's regulations contain a limited exception to this principle, which is not applicable to the General Duty Clause.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>155</SU>
                             The specific prohibition on enforcement of the General Duty Clause by citizen suit must govern over the general enforceability of title V permits. 
                            <E T="03">See Nitro-Lift Technologies L.L.C.</E>
                             v. 
                            <E T="03">Howard,</E>
                             568 U.S. 17, 21 (2012).
                        </P>
                    </FTNT>
                    <P>
                        Other text within the General Duty Clause further evinces congressional intent that the General Duty Clause would not be implemented through permitting. The statute indicates that the CAA section 112(r)(1) general duty shall be “in the same manner and to the same extent as section 654 of title 29”—that is, the general duty clause within the Occupational Safety and Health Act (OSH Act). The OSH Act provision, enacted in 1970, is not implemented through site-specific permits, nor are citizen suits authorized to enforce it. 
                        <E T="03">See generally</E>
                         29 U.S.C. 651-678. If Congress had intended the CAA General Duty clause to be implemented in a fundamentally different manner than the OSH Act provision on which it was explicitly modeled—
                        <E T="03">e.g.,</E>
                         through a permitting program that could be enforced by citizens—it could have specifically said so. However, instead, Congress precluded citizen enforcement under the CAA General Duty Clause, and nowhere did Congress imply that it would be implemented through permitting.
                    </P>
                    <P>
                        Additionally, the CAA requires that states have the authority to enforce title V permits in order to receive EPA approval of their permitting programs. 42 U.S.C. 7661a(b)(5); 
                        <E T="03">see also</E>
                         40 CFR 70.4(b)(3). However, the CAA General Duty Clause is enforceable only by the federal government. The EPA has not delegated authority to implement or enforce the General Duty Clause to state or local air agencies.
                        <SU>156</SU>
                        <FTREF/>
                         Were the requirements of the General Duty Clause considered “applicable requirements” to be included within individual title V permits, states would be unable to enforce these new permit provisions, which would contradict CAA section 502(b)(5). This would mean that all state and local title V programs would be fundamentally flawed—an absurd result Congress could not have intended.
                    </P>
                    <FTNT>
                        <P>
                            <SU>156</SU>
                             Because CAA section 304 is the only federal authority through which citizens 
                            <E T="03">and</E>
                             state or local air agencies could enforce this type of CAA requirement, neither citizens nor state and local air agencies may enforce the General Duty Clause under the CAA. Additionally, some states are prohibited by state law from having general duty authorities. 58 FR 62262, 62278 (Nov. 26, 1993).
                        </P>
                    </FTNT>
                    <P>
                        Notably, each of the relevant statutory provisions discussed earlier—the General Duty Clause of section 112(r)(1), the relevant portion of section 304 authorizing citizen suits to enforce title V permit terms, and the entirety of title V—were promulgated in the same legislative package: the 1990 CAA Amendments. Accordingly, the statutory conflict between these provisions is best understood as reflecting an intentional choice by Congress to fundamentally distinguish the General Duty Clause in section 112(r)(1) from other CAA requirements that would be implemented through the title V permitting program.
                        <SU>157</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>157</SU>
                             
                            <E T="03">See Maracich</E>
                             v. 
                            <E T="03">Spears,</E>
                             570 U.S. 48, 65 (2013) (“It is necessary and required that an interpretation of a phrase of uncertain reach is not confined to a single sentence when the text of the whole statute gives instruction as to its meaning.”); 
                            <E T="03">see also Erlenbaugh</E>
                             v. 
                            <E T="03">United States,</E>
                             409 U.S. 239, 243-45 (1972) (“[
                            <E T="03">In pari materia</E>
                            ] is but a logical extension of the principle that individual sections of a single statute should be construed together . . . . [T]he rule's application certainly makes the most sense when the statutes were enacted by the same legislative body at the same time.”); 
                            <E T="03">United States</E>
                             v. 
                            <E T="03">Ron Pair Enterprises,</E>
                             489 U.S. 235, 242 (1989) (“The plain meaning of legislation should be conclusive, except in the rare cases in which the literal application of a statute will produce a result demonstrably at odds with the intentions of its drafters.” (internal quotation omitted)).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">2. Regulatory Provisions</HD>
                    <P>
                        Following the statutory text, the EPA's regulations provide: “All terms and conditions in a part 70 permit . . . are enforceable by the Administrator and citizens under the Act.” 40 CFR 70.6(b)(1).
                        <SU>158</SU>
                        <FTREF/>
                         Additionally, in order to be approvable by the EPA, state programs under part 70 must demonstrate authority to enforce permits. 40 CFR 70.4(b)(3)(vii). Neither of these regulatory requirements are compatible with the view that the General Duty Clause—which is enforceable only by the EPA—should be included in title V permits.
                    </P>
                    <FTNT>
                        <P>
                            <SU>158</SU>
                             This principle is subject to one exception: certain terms in a title V permit that are not based on the CAA may be labeled as “state-only” requirements that are not federally enforceable or enforceable by citizens through section 304. 40 CFR 70.6(b)(2). The General Duty Clause, which is contained within the CAA, is not eligible for this treatment. Beyond this limited exception, neither the statute nor regulations contemplate other means by which the enforceability of title V permit terms could be restricted in a manner consistent with the limitations in the General Duty Clause discussed earlier.
                        </P>
                    </FTNT>
                    <P>
                        The EPA must read its regulations in a manner consistent with the statute. As explained in the 
                        <E T="03">Hazlehurst</E>
                         and 
                        <E T="03">Owens-Brockway</E>
                         petition orders, the existing definition of “applicable requirement” can reasonably be read to exclude the General Duty Clause of CAA section 112(r)(1).
                        <SU>159</SU>
                        <FTREF/>
                         Nonetheless, in order to provide maximum clarity to the public, the EPA is proposing to revise the definition of “applicable requirement” in 40 CFR 70.1 and 71.2 to make this more explicit.
                    </P>
                    <FTNT>
                        <P>
                            <SU>159</SU>
                             
                            <E T="03">See Hazlehurst Order</E>
                             at 9-10; 
                            <E T="03">Owens-Brockway Order</E>
                             at 23-24.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">3. EPA Guidance and Implementation</HD>
                    <P>
                        Excluding the General Duty Clause from the regulatory definition of “applicable requirement” is consistent with how the EPA has described and implemented both the title V and 112(r) programs since their inception in the early 1990s.
                        <SU>160</SU>
                        <FTREF/>
                         In various rulemaking actions, the EPA has consistently indicated that the only applicable requirements related to 112(r) that need to be satisfied through title V are those related to section 112(r)(7) risk management plans under 40 CFR part 68. 
                        <E T="03">See, e.g.,</E>
                         57 FR at 32275-76; 60 FR 13526, 13526, 13535-36 (Mar. 13, 1995); 61 FR 31668, 31688-89 (June 20, 
                        <PRTPAGE P="1186"/>
                        1996).
                        <SU>161</SU>
                        <FTREF/>
                         The EPA has made similar determinations in early title V petition orders. For example, in the 1997 
                        <E T="03">Shintech I Order,</E>
                         the EPA concluded that “compliance with the provisions of 40 CFR 68.215 . . . is sufficient to satisfy the legal obligations of section 112(r) for purposes of part 70.” 
                        <SU>162</SU>
                        <FTREF/>
                         The EPA therefore specifically rejected the petitioners' request for additional permit terms related to section 112(r)(l), while noting the independent enforceability of the General Duty Clause.
                        <SU>163</SU>
                        <FTREF/>
                         These principles hold true regardless of whether a source is subject to risk management plan requirements under part 68. For example, in the 2001 
                        <E T="03">Pencor-Masada I Order,</E>
                         the EPA applied similar principles to a source that was not subject to part 68. There, the EPA reiterated that a source's obligations under the General Duty Clause are unaffected by compliance with part 68 or the terms of a source's title V permit.
                        <SU>164</SU>
                        <FTREF/>
                         The EPA has made similar statements concerning title V and CAA section 112(r) in other guidance documents.
                        <SU>165</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>160</SU>
                             The EPA understands that most, and perhaps all, permitting authorities implementing part 70 programs have historically followed the same view.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>161</SU>
                             This proposed rule does not affect the risk management plan program under section 112(r)(7) or part 68 in any way. However, the limited intersection between section 112(r)(7) risk management plans and title V permits provides context for the EPA's position on the section 112(r)(1) General Duty Clause. The EPA has, through rulemaking, limited the extent to which even the 112(r)(7)-related “applicable requirements” would be implemented through title V. Specifically, when the EPA promulgated the final part 68 risk management plan rules in 1996, the agency determined that “generic terms in [title V] permits and certain minimal oversight activities” would assure compliance with risk management plan requirements. 61 FR at 31689; 
                            <E T="03">see also</E>
                             57 FR at 32275 (“The EPA recognizes, however, that an RMP is not in any sense a `permit' to release substances addressed therein, and that section 112(r) was not intended to be primarily implemented or enforced through title V.” (citing 42 U.S.C. 7412(r)(7)(F)). For sources subject to both part 68 and title V, these permit content and state oversight requirements are codified at 40 CFR 68.215. For additional information concerning the limited intersection between risk management plans and title V permits, 
                            <E T="03">see In the Matter of Newark Bay,</E>
                             Order on Petition No. II-2019-4 at 9-16 (Aug. 16, 2019). Requiring title V permits to include permit terms related to the General Duty Clause that are even more specific than those the EPA has established for risk management plans would go well beyond the EPA's long-held view of the scope of section 112(r)-related “applicable requirements” that would be implemented through title V.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>162</SU>
                             
                            <E T="03">In the Matter of Shintech Inc., PVC Plant,</E>
                             Order on Petition, 12 (Sept. 10, 1997).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>163</SU>
                             Specifically, the EPA emphasized that “compliance with the requirements of part 68 does not relieve Shintech of its legal obligation to meet the general duty requirements of section 112(r)(1) of the Act . . . . Section 112(r)(1) remains a self-implementing requirement of the Act, and EPA expects and requires all covered sources to comply with the general duty provisions of 112(r)(1).” 
                            <E T="03">Shintech I Order</E>
                             at 12 n.9. The EPA also explained that it would be improper to shield a source from liability under the General Duty Clause using a title V permit shield. 
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>164</SU>
                             
                            <E T="03">See Pencor-Masada I Order</E>
                             at 31-32 n.38.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>165</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Memorandum, 
                            <E T="03">Title V Program Approval Criteria for Section 112 Activities</E>
                             (April 13, 1993), available at 
                            <E T="03">https://www.epa.gov/sites/production/files/2015-08/documents/t5-112.pdf;</E>
                             Memorandum, 
                            <E T="03">Relationship between the Part 70 Operating Permit Program and Section 112(r)</E>
                             (June 24, 1994), available at 
                            <E T="03">https://www.epa.gov/sites/production/files/2015-08/documents/opp112r.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        Similar to the EPA's title V guidance, the EPA's longstanding guidance concerning the implementation of the General Duty Clause similarly suggests that the General Duty Clause is not to be implemented through title V. Notably, in the EPA's comprehensive Guidance for Implementation of the General Duty Clause (“GDC Guidance”),
                        <SU>166</SU>
                        <FTREF/>
                         the EPA details the mechanisms through which the General Duty Clause would be implemented and enforced, and never once mentions permitting as an available mechanism.
                    </P>
                    <FTNT>
                        <P>
                            <SU>166</SU>
                             
                            <E T="03">Guidance for Implementation of the General Duty Clause, Clean Air Act Section 112(r)(1),</E>
                             EPA 550-B00-002 (May 2000), available at 
                            <E T="03">https://www.epa.gov/sites/production/files/documents/gendutyclause-rpt.pdf.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">4. Additional Policy Considerations</HD>
                    <P>
                        If the EPA were to consider the General Duty Clause an applicable requirement with which title V permit must assure compliance, this would have significant programmatic impacts, upsetting the administration of both the title V and General Duty Clause programs nationwide. For example, The EPA expects that the majority of major sources subject to the title V program may, at some time or another, also have obligations under the General Duty Clause. If the General Duty Clause was considered an applicable requirement, thousands of title V permits nationwide would need to be reopened to include conditions necessary to identify and assure compliance with the clause. Such an enormous resource burden on the permitting authorities that implement the title V program would hardly make sense given that these same permitting authorities cannot enforce the General Duty Clause.
                        <SU>167</SU>
                        <FTREF/>
                         This is clearly not an outcome that either Congress or the EPA envisioned when establishing these two programs.
                        <SU>168</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>167</SU>
                             No statutory or regulatory mechanism currently exists for the EPA to establish General Duty Clause requirements for all title V sources nationwide. Even if it did, implementation of any such mechanism this would present an even greater resource issue for the EPA, and would run against Congress's intent that the title V program is to be primarily implemented by the states, not the EPA. 
                            <E T="03">See</E>
                             42 U.S.C. 7661a; 
                            <E T="03">see, e.g., Env't Integrity Project,</E>
                             969 F.3d at 536, 545.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>168</SU>
                             The EPA, like Congress, does not “hide elephants in mouseholes.” 
                            <E T="03">See Whitman</E>
                             v. 
                            <E T="03">Am. Trucking Ass'ns,</E>
                             531 U.S. 457, 468 (2001).
                        </P>
                    </FTNT>
                    <P>
                        Other practical concerns—closely related to the legal issues discussed previously—weigh against implementing the General Duty Clause through title V. For example, how could a title V permit containing General Duty Clause requirements be structured in order to avoid the statutory constraints on enforcement discussed earlier? Neither the Act nor the EPA's regulations provide that certain portions of the title V permit can be labeled “enforceable only by the EPA.” To the contrary, all federally-enforceable permit terms must necessarily be enforceable by the state agencies issuing the permits as well as the public at large. 
                        <E T="03">See</E>
                         42 U.S.C. 7604(a)(1), (f)(4), 7661a(b)(5)(E), 7661c(c); 40 CFR 70.4(b)(3)(vii), 70.6(b)(1). Additionally, if the General Duty Clause were considered an “applicable requirement” that states have no authority to enforce, the EPA could face pressure to issue notices of deficiency to all 117 state, local, and Tribal permitting authorities nationwide for their failure to enforce all aspects of the title V program. 
                        <E T="03">See</E>
                         40 CFR 70.10(b), (c)(1), Appx A. Moreover, the EPA could face pressure to take over the issuance of all title V permits, or to issue partial permits to nearly every title V source to cover these sources' General Duty Clause obligations. 
                        <E T="03">See</E>
                         40 CFR 70.10(b)(2)(iii); 
                        <E T="03">see also</E>
                         40 CFR part 71. These are clearly not reasonable propositions,
                        <SU>169</SU>
                        <FTREF/>
                         but nonetheless ones that could inevitably follow if the EPA were to consider the General Duty Clause an “applicable requirement” for title V purposes.
                    </P>
                    <FTNT>
                        <P>
                            <SU>169</SU>
                             Such outcomes would be contrary to congressional intent for the title V program to be primarily administered by states.
                        </P>
                    </FTNT>
                    <P>
                        In addition to these untenable impacts to title V permitting, determining that the General Duty Clause must be included in title V permits would fundamentally alter the EPA's implementation and enforcement of the General Duty Clause itself. The EPA has historically described the General Duty Clause as a “self-executing requirement.” 61 FR 31668, 31680 (June 20, 1996).
                        <SU>170</SU>
                        <FTREF/>
                         This means, quite simply, 
                        <PRTPAGE P="1187"/>
                        that the General Duty Clause is meant to be implemented and enforced independently as a direct requirement of the CAA, beyond the strictures of any set of regulations or the title V permitting program.
                    </P>
                    <FTNT>
                        <P>
                            <SU>170</SU>
                             The EPA has also described the General Duty Clause as a “self-enabling” or “self-implementing” requirement. 
                            <E T="03">See</E>
                             Letter from Mathy Stanislaus, Assistant Administrator, EPA Office of Solid Waste and Emergency Response, to Hon. Mike Pompeo, U.S. House of Representatives (Aug. 1, 2013)) (Stanislaus-Pompeo Letter); 
                            <E T="03">Owens-Brockway Order</E>
                             at 27; 
                            <E T="03">Hazlehurst Order</E>
                             at 12; 
                            <E T="03">Pencor-Masada I Order</E>
                             at 32 n.38; 
                            <E T="03">Shintech I Order</E>
                             at 12 n.9. As discussed in section III.E. of this preamble, the EPA has also used the term “self-implementing” to refer to certain types of requirements in other CAA programs, including NSPS and NESHAP standards. The intent of this phrase is slightly different in the context of the General Duty Clause than in the context of NSPS and NESHAP standards. The requirements of the General Duty Clause flow directly from the statute and are implemented in the absence of implementing regulations. By 
                            <PRTPAGE/>
                            contrast, emission standards like NSPS or NESHAP standards are generally “self-implementing” once regulations are promulgated. The similarity is that in both situations, the self-implementing requirements are enforceable regardless of whether they are reflected in a title V permit.
                        </P>
                    </FTNT>
                    <P>
                        Although the title V permitting program offers clear benefits for identifying and assuring compliance with other types of more typical emission standard-based requirements under regulations promulgated under the CAA, the title V program is a particularly poor fit for implementing the General Duty Clause. The General Duty Clause is, as its name suggests, a 
                        <E T="03">general</E>
                         duty. Identifying 
                        <E T="03">specific</E>
                         obligations within each source's title V permit would conflict with the notion of a general duty. Moreover, determining whether an individual source has satisfied this general duty is highly circumstance-specific. The EPA interprets the General Duty Clause to generally require owners and operators to adhere to recognized industry practices and standards in addition to any applicable government regulations. GDC Guidance at 2, 11-12. However, there may be situations where circumstances make a particular industry standard or municipal code inapplicable, unsuitable, or insufficient for a given source, and there may be other ways to abate hazards than those listed in a particular industry standard or municipal code. Each source's obligations are dependent on the detailed knowledge of each individual source. Even in the absence of an industry standard, a source's knowledge of a potential hazard and a feasible means to abate it is relevant to its general duty under CAA section 112(r)(1). 
                        <E T="03">See</E>
                         GDC Guidance at 12. Should a source learn of a hazard and a feasible means to abate it after its permit is written, the General Duty Clause would ordinarily hold the source responsible for its knowledge. Given that the factual circumstances and knowledge at the source, as well as any relevant industry guidelines, can change frequently, the source's obligation under the General Duty Clause are necessarily fluid. If General Duty Clause obligations were to be included in title V permits as applicable requirements, the relevant permit terms would need to be constantly updated to accurately reflect a source's obligations. Overall, identifying specific General Duty Clause requirements would not only curtail the flexibilities rightly available to a source, but it would also undermine the General Duty Clause by limiting the scope of a source's potential obligations to those specific requirements contained in the permit.
                        <SU>171</SU>
                        <FTREF/>
                         For these reasons, the EPA has rejected requests to define and restrict General Duty Clause obligations through rulemaking.
                        <SU>172</SU>
                        <FTREF/>
                         It would be similarly inappropriate to define and restrict these obligations through title V permit terms.
                    </P>
                    <FTNT>
                        <P>
                            <SU>171</SU>
                             Were the General Duty Clause treated as a permit term, a source could argue it was shielded from its duty by the terms of the permit for hazards identified after the permit was issued. The potential for sources to request a title V permit shield to cover General Duty Clause obligations would exacerbate these concerns, notwithstanding that such a permit shield would not be appropriate, as the EPA has previously explained. 
                            <E T="03">See Shintech I Order</E>
                             at 12 n.9.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>172</SU>
                             
                            <E T="03">E.g.,</E>
                             Stanislaus-Pompeo Letter.
                        </P>
                    </FTNT>
                    <P>In summary, the CAA specifically prohibits the General Duty Clause from being enforced through the citizen suit provision in section 304 that is available for all standards and limitations included in title V permits. Therefore, the EPA must draft and interpret its regulations such that the General Duty Clause is not an applicable requirement for purposes of title V permitting. Although the current part 70 and 71 regulations can be interpreted as consistent with this position, the EPA proposes to amend the regulations to make this more explicit. This change is consistent with the EPA's implementation of both the title V and General Duty Clause programs since their inception in the early 1990s. Moreover, this proposed amendment is consistent with sound policy and avoids nationwide programmatic impacts that would follow if the EPA attempted to implement the General Duty Clause through title V.</P>
                    <HD SOURCE="HD1">VI. 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, Executive Order 13563: Improving Regulation and Regulatory Review, and Executive Order 14094: Modernizing Regulatory Review</HD>
                    <P>This action is not a significant regulatory action as defined in Executive Order 12866, as amended by Executive Order 14094, and was therefore not subject to a requirement for Executive Order 12866 review.</P>
                    <HD SOURCE="HD2">B. Paperwork Reduction Act (PRA)</HD>
                    <P>This action does not impose any new information collection burden under the PRA. OMB has previously approved the information collection activities contained in the existing regulations and has assigned OMB control numbers 2060-0243 (for the part 70 state operating permit programs) and 2060-0336 (for the part 71 federal operating permit program). The clarifications to the regulations proposed in this action do not directly change any of the information collection activities previously approved by OMB. To the extent that the proposed action impacts permitting authorities or permittees, any impacts would fall under, and potentially reduce the burden of completing, the activities already accounted for in the supporting statement for these information collection requests.</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. This action will not directly impose any requirements on small entities. This proposed rule primarily concerns the EPA's exercise of the agency's oversight obligations when reviewing title V permits issued by state, local, and Tribal permitting authorities, when reviewing title V petitions submitted by any person, and when issuing title V permits under 40 CFR part 71. This action would not directly impose any requirements on the entities involved in these processes (including permitting authorities, permittees, and members of the public). Although those entities could eventually be affected by case-by-case decisions made when the EPA exercises its oversight and/or permitting authorities, the economic impact of any such future decisions on any small entities is expected to be minimal and not adverse. For example, the proposed rule would reduce uncertainty, and potentially cost, for small entities that obtain both NSR and title V permits by clarifying the limited circumstances under which NSR permitting decisions would be subject to additional EPA scrutiny through the title V permitting process.</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 
                        <PRTPAGE P="1188"/>
                        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 effect on the states, on the relationship between the national government and the states, or on the distribution of power and responsibilities among the various levels of government. Additional information about how this action could indirectly impact states is included in section IV.D.2. of this preamble.</P>
                    <HD SOURCE="HD2">F. Executive Order 13175: Consultation and Coordination With Indian Tribal Governments</HD>
                    <P>This action has Tribal implications. However, it will neither impose substantial direct compliance costs on federally recognized Tribal governments, nor preempt Tribal law. One Tribal government (the Southern Ute Indian Tribe) currently administers an approved part 70 operating permit program, and one Tribal government (the Navajo Nation) currently administers a part 71 operating permit program pursuant to a delegation agreement with the EPA. This rulemaking does not require those entities to take any specific actions, as described in section IV.D.2. of this preamble. The EPA informally engaged with Tribal officials under the EPA Policy on Consultation and Coordination with Indian Tribes early in the process of developing this regulation to permit them to have meaningful and timely input into its development. Specifically, prior to issuing this proposed rule, the EPA conducted outreach with Tribal representatives through a call with the National Tribal Air Association. Further, the Agency offered to further discuss this action with the Southern Ute Indian Tribe and Navajo Nation. The EPA also solicits comment from affected Tribal governments on the implications of this rulemaking.</P>
                    <HD SOURCE="HD2">G. Executive Order 13045: Protection of Children From Environmental Health and Safety Risks</HD>
                    <P>The EPA interprets Executive Order 13045 as applying only to those regulatory actions that concern environmental health or safety risks that EPA has reason to believe may disproportionately affect children, per the definition of “covered regulatory action” in section 2-202 of the Executive Order.</P>
                    <P>Therefore, this action is not subject to Executive Order 13045 because it does not concern an environmental health risk or safety risk. Since this action does not concern human health, the EPA's Policy on Children's Health also does not apply.</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 subject to Executive Order 13211, because it is not a significant regulatory action under Executive Order 12866.</P>
                    <HD SOURCE="HD2">I. National Technology Transfer and Advancement Act</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>The EPA finds that it is not practicable to assess whether the human health or environmental conditions that exist prior to this action result in disproportionate and adverse effects on communities with environmental justice concerns. The issues addressed in this rulemaking neither directly impact the levels of pollution that regulated entities subject to title V and/or NSR permitting may emit, nor the distribution of such regulated entities relative to communities with environmental justice interests. Rather, the issues in this rule are primarily procedural and apply uniformly across the nation.</P>
                    <P>This proposed rule seeks to codify the EPA's existing positions, so impacts are expected to be generally minimal across the board. To the extent this action may impact communities with environmental justice concerns, such impacts are expected to mirror those affecting the public at large. These expected impacts on the public are explained in section IV.D.4. of this preamble. In summary, this rule will provide more clarity to the public about the most appropriate, and most effective, avenues in which they can raise concerns with different types of permitting decisions. It will also incentivize states to offer more meaningful public engagement on NSR permitting decisions.</P>
                    <P>The EPA provided pre-proposal outreach to community and environmental justice groups during a regularly scheduled National Environmental Justice Community Engagement teleconference and plans to offer more detailed outreach after this proposal is published.</P>
                    <HD SOURCE="HD1">VII. Statutory Authority</HD>
                    <P>
                        The statutory authority for this action is provided by 42 U.S.C. 7401 
                        <E T="03">et seq.</E>
                         More specifically, CAA sections 502(b) and 502(d)(3), 42 U.S.C. 7661a(b) &amp; (d)(3), which direct the Administrator of the EPA to promulgate regulations establishing state operating permit programs and give the Administrator the authority to establish a federal operating permit program. Additionally, the Administrator determines that this proposed action is subject to the provisions of CAA section 307(d), which establish procedural requirements specific to rulemaking under the CAA. CAA section 307(d)(1)(V) provides that the provisions of CAA section 307(d) apply to “such other actions as the Administrator may determine.” 42 U.S.C. 7607(d)(1)(V).
                    </P>
                    <LSTSUB>
                        <HD SOURCE="HED">List of Subjects</HD>
                        <CFR>40 CFR Part 70</CFR>
                        <P>Environmental protection, Administrative practice and procedure, Air pollution control, Intergovernmental relations, Reporting and recordkeeping requirements.</P>
                        <CFR>40 CFR Part 71</CFR>
                        <P>Environmental protection, Administrative practice and procedure, Air pollution control, Reporting and recordkeeping requirements.</P>
                    </LSTSUB>
                    <SIG>
                        <NAME>Michael S. Regan,</NAME>
                        <TITLE>Administrator.</TITLE>
                    </SIG>
                    <P>For the reasons set forth in the preamble, the EPA proposes to amend 40 CFR parts 70 and 71 as follows:</P>
                    <PART>
                        <HD SOURCE="HED">PART 70—STATE OPERATING PERMIT PROGRAMS</HD>
                    </PART>
                    <AMDPAR>1. The authority citation for part 70 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                             42 U.S.C. 7401, 
                            <E T="03">et seq.</E>
                        </P>
                    </AUTH>
                    <AMDPAR>2. Amend § 70.2 by revising paragraphs (1), (2), and (4) for the definition “Applicable requirement” to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 70.2</SECTNO>
                        <SUBJECT>Definitions.</SUBJECT>
                        <STARS/>
                        <P>
                            <E T="03">Applicable requirement</E>
                             * * *
                        </P>
                        <P>
                            (1) Any standard or other requirement provided for in the applicable implementation plan approved or promulgated by EPA through rulemaking under title I of the Act that implements the relevant requirements of the Act, including any revisions to that plan promulgated in part 52 of this chapter, provided that where a preconstruction permit described in paragraph (2) of this definition is issued 
                            <PRTPAGE P="1189"/>
                            with public notice and the opportunity for comment and judicial review, the terms and conditions of such a permit establish and define, for purposes of this paragraph, the applicable requirements of the implementation plan that apply to the activities authorized by such a preconstruction permit;
                        </P>
                        <P>(2) Any term or condition of any preconstruction permits issued pursuant to regulations approved or promulgated through rulemaking under title I, including parts C or D or section 110(a)(2)(C), of the Act;</P>
                        <STARS/>
                        <P>(4) Any standard or other requirement under section 112 of the Act, including any requirement concerning accident prevention under section 112(r)(7) of the Act, but not including any requirement under section 112(r)(1) of the Act;</P>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>3. Amend § 70.7 by:</AMDPAR>
                    <AMDPAR>a. Revising paragraph (d)(1)(iv);</AMDPAR>
                    <AMDPAR>b. Removing and reserving paragraph (d)(1)(v); and</AMDPAR>
                    <AMDPAR>c. Removing paragraph (d)(4).</AMDPAR>
                    <P>The revision reads as follows:</P>
                    <SECTION>
                        <SECTNO>§ 70.7</SECTNO>
                        <SUBJECT>Permit issuance, renewal, reopenings, and revisions.</SUBJECT>
                        <STARS/>
                        <P>(d) * * *</P>
                        <P>(1) * * *</P>
                        <P>(iv) Allows for a change in ownership or operational control of a source where the permitting authority determines that no other change in the permit is necessary, provided that a written agreement containing a specific date for transfer of permit responsibility, coverage, and liability between the current and new permittee has been submitted to the permitting authority; or</P>
                        <P>(v) [Reserved]</P>
                        <STARS/>
                    </SECTION>
                    <PART>
                        <HD SOURCE="HED">PART 71—FEDERAL OPERATING PERMIT PROGRAMS</HD>
                    </PART>
                    <AMDPAR>4. The authority citation for part 71 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                             42 U.S.C. 7401, 
                            <E T="03">et seq.</E>
                        </P>
                    </AUTH>
                    <AMDPAR>5. Amend § 71.2 by revising paragraphs (1), (2), and (4) for the definition “Applicable requirement” to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 71.2</SECTNO>
                        <SUBJECT>Definitions.</SUBJECT>
                        <STARS/>
                        <P>
                            <E T="03">Applicable requirement</E>
                             * * *
                        </P>
                        <P>(1) Any standard or other requirement provided for in the applicable implementation plan approved or promulgated by EPA through rulemaking under title I of the Act that implements the relevant requirements of the Act, including any revisions to that plan promulgated in part 52 of this chapter, provided that where a preconstruction permit described in paragraph (2) of this definition is issued with public notice and the opportunity for comment and judicial review, the terms and conditions of such a permit establish and define, for purposes of this paragraph, the applicable requirements of the implementation plan that apply to the activities authorized by such a preconstruction permit;</P>
                        <P>(2) Any term or condition of any preconstruction permits issued pursuant to regulations approved or promulgated through rulemaking under title I, including parts C or D or section 110(a)(2)(C), of the Act;</P>
                        <STARS/>
                        <P>(4) Any standard or other requirement under section 112 of the Act, including any requirement concerning accident prevention under section 112(r)(7) of the Act, but not including any requirement under section 112(r)(1) of the Act;</P>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>6. Amend § 71.7 by:</AMDPAR>
                    <AMDPAR>a. Revising paragraph (d)(1)(iv);</AMDPAR>
                    <AMDPAR>b. Removing and reserving paragraph (d)(1)(v); and</AMDPAR>
                    <AMDPAR>c. Removing paragraph (d)(4).</AMDPAR>
                    <P>The revision reads as follows:</P>
                    <SECTION>
                        <SECTNO>§ 71.7</SECTNO>
                        <SUBJECT>Permit issuance, renewal, reopenings, and revisions.</SUBJECT>
                        <STARS/>
                        <P>(d) * * *</P>
                        <P>(1) * * *</P>
                        <P>(iv) Allows for a change in ownership or operational control of a source where the permitting authority determines that no other change in the permit is necessary, provided that a written agreement containing a specific date for transfer of permit responsibility, coverage, and liability between the current and new permittee has been submitted to the permitting authority; or</P>
                        <P>(v) [Reserved]</P>
                        <STARS/>
                    </SECTION>
                </SUPLINF>
                <FRDOC>[FR Doc. 2023-27759 Filed 1-8-24; 8:45 am]</FRDOC>
                <BILCOD>BILLING CODE 6560-50-P</BILCOD>
            </PRORULE>
        </PRORULES>
    </NEWPART>
    <VOL>89</VOL>
    <NO>6</NO>
    <DATE>Tuesday, January 9, 2024</DATE>
    <UNITNAME>Rules and Regulations</UNITNAME>
    <NEWPART>
        <PTITLE>
            <PRTPAGE P="1191"/>
            <PARTNO>Part III</PARTNO>
            <AGENCY TYPE="P">Department of Health and Human Services</AGENCY>
            <CFR> 45 Parts 170 and 171</CFR>
            <TITLE>Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing; Final Rule</TITLE>
        </PTITLE>
        <RULES>
            <RULE>
                <PREAMB>
                    <PRTPAGE P="1192"/>
                    <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                    <SUBAGY>Office of the Secretary</SUBAGY>
                    <CFR>45 CFR Parts 170, 171</CFR>
                    <RIN>RIN 0955-AA03</RIN>
                    <SUBJECT>Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing</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.</P>
                    </ACT>
                    <SUM>
                        <HD SOURCE="HED">SUMMARY:</HD>
                        <P>This final rule implements the Electronic Health Record (EHR) Reporting Program provision of the 21st Century Cures Act by establishing new Conditions and Maintenance of Certification requirements for health information technology (health IT) developers under the ONC Health IT Certification Program (Program). This final rule also makes several updates to certification criteria and standards recognized by the Program. The Program updates include revised certification criteria for “decision support interventions,” “patient demographics and observations,” and “electronic case reporting,” as well as a new baseline version of the United States Core Data for Interoperability (USCDI) standard to Version 3. Additionally, this final rule provides enhancements to support information sharing under the information blocking regulations. The implementation of these provisions advances interoperability, improves algorithm transparency, and supports the access, exchange, and use of electronic health information (EHI). This final rule also updates numerous technical standards in the Program in additional ways to advance interoperability, enhance health IT certification, and reduce burden and costs for health IT developers and users of health IT.</P>
                    </SUM>
                    <EFFDATE>
                        <HD SOURCE="HED">DATES:</HD>
                        <P/>
                        <P>
                            <E T="03">Effective date:</E>
                             This final rule is effective on February 8, 2024.
                        </P>
                        <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 February 8, 2024.
                        </P>
                    </EFFDATE>
                    <FURINF>
                        <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                        <P>Michael Lipinski, Office of Policy, Office of the National Coordinator for Health Information Technology, 202-690-7151.</P>
                    </FURINF>
                </PREAMB>
                <SUPLINF>
                    <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                    <P/>
                    <HD SOURCE="HD1">Table of Contents</HD>
                    <EXTRACT>
                        <FP SOURCE="FP-2">I. Executive Summary</FP>
                        <FP SOURCE="FP1-2">A. Purpose of Regulatory Action</FP>
                        <FP SOURCE="FP1-2">1. Statutory Responsibilities and Implementation</FP>
                        <FP SOURCE="FP1-2">2. Administration Executive Orders</FP>
                        <FP SOURCE="FP1-2">3. Federal Coordination</FP>
                        <FP SOURCE="FP1-2">B. Summary of Major Provisions</FP>
                        <FP SOURCE="FP1-2">1. ONC Health IT Certification Program Updates</FP>
                        <FP SOURCE="FP1-2">a. “The ONC Certification Criteria for Health IT” and Discontinuing Year Themed “Editions”</FP>
                        <FP SOURCE="FP1-2">b. New and Revised Standards and Certification Criteria</FP>
                        <FP SOURCE="FP1-2">i. The United States Core Data for Interoperability Version 3 (USCDI v3)</FP>
                        <FP SOURCE="FP1-2">ii. C-CDA Companion Guide Updates</FP>
                        <FP SOURCE="FP1-2">iii. “Minimum Standards” Code Sets Updates</FP>
                        <FP SOURCE="FP1-2">iv. Electronic Case Reporting</FP>
                        <FP SOURCE="FP1-2">v. Decision Support Interventions and Predictive Models</FP>
                        <FP SOURCE="FP1-2">vi. Synchronized Clocks Standard</FP>
                        <FP SOURCE="FP1-2">vii. Standardized API for Patient and Population Services</FP>
                        <FP SOURCE="FP1-2">viii. Patient Demographics and Observations Certification Criterion in § 170.315(a)(5)</FP>
                        <FP SOURCE="FP1-2">ix. Updates to Transitions of Care Certification Criterion in § 170.315(b)(1)</FP>
                        <FP SOURCE="FP1-2">x. Patient Right To Request a Restriction on Use or Disclosure</FP>
                        <FP SOURCE="FP1-2">xi. Requirement for Health IT Developers To Update Their Previously Certified Health IT</FP>
                        <FP SOURCE="FP1-2">2. Assurances Condition and Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">3. Real World Testing—Inherited Certified Status</FP>
                        <FP SOURCE="FP1-2">4. Insights Condition and Maintenance of Certification</FP>
                        <FP SOURCE="FP1-2">5. Information Blocking Enhancements</FP>
                        <FP SOURCE="FP1-2">C. Costs and Benefits</FP>
                        <FP SOURCE="FP-2">II. Background</FP>
                        <FP SOURCE="FP1-2">A. Statutory Basis</FP>
                        <FP SOURCE="FP1-2">1. Standards, Implementation Specifications, and Certification Criteria</FP>
                        <FP SOURCE="FP1-2">2. Health IT Certification Program(s)</FP>
                        <FP SOURCE="FP1-2">B. Regulatory History</FP>
                        <FP SOURCE="FP1-2">C. General Comments on the HTI-1 Proposed Rule</FP>
                        <FP SOURCE="FP-2">III. ONC Health IT Certification Program Updates</FP>
                        <FP SOURCE="FP1-2">A. “The ONC Certification Criteria for Health IT” and Discontinuing Year Themed “Editions,” Definition of Revised Certification Criterion, and Related Program Oversight</FP>
                        <FP SOURCE="FP1-2">1. Discontinuing Year Themed “Editions”</FP>
                        <FP SOURCE="FP1-2">2. Definition of “Revised Certification Criterion”</FP>
                        <FP SOURCE="FP1-2">3. Program Oversight Related to Discontinuation of Editions</FP>
                        <FP SOURCE="FP1-2">a. Records Retention</FP>
                        <FP SOURCE="FP1-2">b. Records Retention—Complete EHR</FP>
                        <FP SOURCE="FP1-2">B. Standards and Implementation Specifications</FP>
                        <FP SOURCE="FP1-2">1. National Technology Transfer and Advancement Act</FP>
                        <FP SOURCE="FP1-2">2. Compliance With Adopted Standards and Implementation Specifications</FP>
                        <FP SOURCE="FP1-2">3. “Reasonably Available” to Interested Parties</FP>
                        <FP SOURCE="FP1-2">C. New and Revised Standards and Certification Criteria</FP>
                        <FP SOURCE="FP1-2">1. The United States Core Data for Interoperability Version 3 (USCDI v3)</FP>
                        <FP SOURCE="FP1-2">a. Certification Criteria That Reference USCDI</FP>
                        <FP SOURCE="FP1-2">b. USCDI Standard—Data Classes and Elements Added Since USCDI v1</FP>
                        <FP SOURCE="FP1-2">2. C-CDA Companion Guide Updates</FP>
                        <FP SOURCE="FP1-2">3. “Minimum Standards” Code Sets Updates</FP>
                        <FP SOURCE="FP1-2">4. Electronic Case Reporting</FP>
                        <FP SOURCE="FP1-2">5. Decision Support Interventions and Predictive Models</FP>
                        <FP SOURCE="FP1-2">a. Requirements for Decision Support Interventions (DSI) Certification Criterion</FP>
                        <FP SOURCE="FP1-2">b. Updates to Real World Testing Condition for CDS Criterion</FP>
                        <FP SOURCE="FP1-2">6. Synchronized Clocks Standard</FP>
                        <FP SOURCE="FP1-2">7. Standardized API for Patient and Population Services</FP>
                        <FP SOURCE="FP1-2">a. Native Applications and Refresh Tokens</FP>
                        <FP SOURCE="FP1-2">b. FHIR United States Core Implementation Guide Version 5.0.1</FP>
                        <FP SOURCE="FP1-2">c. FHIR Endpoint for Service Base URLs</FP>
                        <FP SOURCE="FP1-2">d. Access Token Revocation</FP>
                        <FP SOURCE="FP1-2">e. SMART App Launch 2.0</FP>
                        <FP SOURCE="FP1-2">8. Patient Demographics and Observations Certification Criterion in § 170.315(a)(5)</FP>
                        <FP SOURCE="FP1-2">9. Updates to Transitions of Care Certification Criterion in § 170.315(b)(1)</FP>
                        <FP SOURCE="FP1-2">10. Patient Right To Request a Restriction on Use or Disclosure</FP>
                        <FP SOURCE="FP1-2">11. Requirement for Health IT Developers To Update Their Previously Certified Health IT</FP>
                        <FP SOURCE="FP1-2">D. Assurances Condition and Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">1. Condition of Certification</FP>
                        <FP SOURCE="FP1-2">2. Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">E. Real World Testing—Inherited Certified Status</FP>
                        <FP SOURCE="FP1-2">F. Insights Condition and Maintenance of Certification</FP>
                        <FP SOURCE="FP1-2">1. Background and Purpose</FP>
                        <FP SOURCE="FP1-2">2. Insights Condition and Maintenance of Certification—Final Measures</FP>
                        <FP SOURCE="FP1-2">3. Insights Condition and Maintenance of Certification—Requirements</FP>
                        <FP SOURCE="FP1-2">4. Insights Condition and Maintenance of Certification—Process for Reporting</FP>
                        <FP SOURCE="FP1-2">G. Requests for Information</FP>
                        <FP SOURCE="FP1-2">1. Laboratory Data Interoperability Request for Information</FP>
                        <FP SOURCE="FP1-2">2. Request for Information on Pharmacy Interoperability Functionality Within the ONC Health IT Certification Program Including Real-Time Prescription Benefit Capabilities</FP>
                        <FP SOURCE="FP1-2">3. FHIR Standard</FP>
                        <FP SOURCE="FP-2">IV. Information Blocking Enhancements</FP>
                        <FP SOURCE="FP1-2">A. General Comments Regarding Information Blocking Enhancements</FP>
                        <FP SOURCE="FP1-2">B. Defined Terms</FP>
                        <FP SOURCE="FP1-2">1. Offer Health Information Technology or Offer Health IT</FP>
                        <FP SOURCE="FP1-2">a. Exclusion of Certain Funding Subsidy Arrangements From Offer Health IT Definition</FP>
                        <FP SOURCE="FP1-2">b. Implementation and Use Activities That Are Not an Offering of Health IT</FP>
                        <FP SOURCE="FP1-2">c. Consulting and Legal Services Exclusion From Offer Health IT Definition</FP>
                        <FP SOURCE="FP1-2">2. Health IT Developer of Certified Health IT: Self-Developer Health Care Providers</FP>
                        <FP SOURCE="FP1-2">
                            3. Information Blocking Definition
                            <PRTPAGE P="1193"/>
                        </FP>
                        <FP SOURCE="FP1-2">C. Exceptions</FP>
                        <FP SOURCE="FP1-2">1. Infeasibility</FP>
                        <FP SOURCE="FP1-2">a. Infeasibility Exception—Uncontrollable Events Condition</FP>
                        <FP SOURCE="FP1-2">b. Infeasibility Exception—Third Party Seeking Modification Use</FP>
                        <FP SOURCE="FP1-2">c. Infeasibility Exception—Manner Exception Exhausted</FP>
                        <FP SOURCE="FP1-2">2. TEFCA Manner Exception</FP>
                        <FP SOURCE="FP1-2">D. Information Blocking Requests for Information</FP>
                        <FP SOURCE="FP1-2">1. Additional Exclusions From Offer Health IT—Request for Information</FP>
                        <FP SOURCE="FP1-2">2. Possible Additional TEFCA Reasonable and Necessary Activities—Request for Information</FP>
                        <FP SOURCE="FP1-2">3. Health IT Capabilities for Data Segmentation and User/Patient Access—Request for Information</FP>
                        <FP SOURCE="FP-2">V. Incorporation by Reference</FP>
                        <FP SOURCE="FP-2">VI. Collection of Information Requirements</FP>
                        <FP SOURCE="FP1-2">A. Independent Entity</FP>
                        <FP SOURCE="FP1-2">B. Health IT Developers</FP>
                        <FP SOURCE="FP1-2">C. ONC-ACBs</FP>
                        <FP SOURCE="FP-2">VII. Regulatory Impact Analysis</FP>
                        <FP SOURCE="FP1-2">A. Statement of Need</FP>
                        <FP SOURCE="FP1-2">B. Alternatives Considered</FP>
                        <FP SOURCE="FP1-2">C. Overall Impact</FP>
                        <FP SOURCE="FP1-2">1. Executive Orders 12866 and 13563—Regulatory Planning and Review Analysis</FP>
                        <FP SOURCE="FP1-2">a. Costs and Benefits</FP>
                        <FP SOURCE="FP1-2">b. Accounting Statement and Table</FP>
                        <FP SOURCE="FP1-2">D. Regulatory Flexibility Act</FP>
                        <FP SOURCE="FP1-2">E. Executive Order 13132—Federalism</FP>
                        <FP SOURCE="FP1-2">F. Unfunded Mandates Reform Act of 1995</FP>
                        <FP SOURCE="FP-2">Regulation Text</FP>
                    </EXTRACT>
                    <HD SOURCE="HD1">I. Executive Summary</HD>
                    <HD SOURCE="HD2">A. Purpose of Regulatory Action</HD>
                    <P>The Office of the National Coordinator for Health Information Technology (ONC) is the principal federal entity charged with coordinating nationwide efforts to implement and use advanced health IT and to facilitate the electronic exchange of health information. ONC is at the forefront of the administration's health IT efforts and is a resource to the entire health system to support the adoption of health IT and the promotion of nationwide, standards-based health information exchange to improve healthcare. ONC is focused on two strategic objectives: (1) advancing the development and use of health IT capabilities; and (2) establishing expectations for data sharing. ONC's overall mission, consistent with the policies adopted in this final rule, is to create systemic improvements in health and care through the access, exchange, and use of data.</P>
                    <P>This final rule fulfills statutory requirements and aligns with administrative priorities; advances equity, innovation, and interoperability; and supports the access, exchange, and use of EHI. It also promotes the responsible development and use of artificial intelligence through transparency and improves patient care through policies that advance standards-based interoperability and EHI exchange, which are central to the Department of Health and Human Services' efforts to enhance and protect the health and well-being of all Americans.</P>
                    <HD SOURCE="HD3">1. Statutory Responsibilities and Implementation</HD>
                    <P>
                        The Secretary of Health and Human Services has delegated to ONC the responsibility to implement certain provisions in Title IV of the 21st Century Cures Act (Pub. L. 114-255, Dec. 13, 2016) (Cures Act) including: the Electronic Health Record (EHR) Reporting Program condition and maintenance of certification requirements under the ONC Health IT Certification Program (Program) and the identification of reasonable and necessary activities that do not constitute information blocking.
                        <SU>1</SU>
                        <FTREF/>
                         ONC is also responsible for implementing certain provisions of the Health Information Technology for Economic and Clinical Health Act (Pub. L. 111-5, Feb. 17. 2009) (HITECH Act) of 2009, including, but not limited to, requirements that the National Coordinator perform duties consistent with the development of a nationwide health information technology infrastructure that allows for the electronic use and exchange of information and that promotes a more effective marketplace, greater competition, and increased consumer choice, as well as requirements to keep, or recognize, a program or programs for the voluntary certification of health information technology.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1</SU>
                             Reasonable and necessary activities that do not constitute information blocking, also known as information blocking exceptions, are identified in 45 CFR part 171 subparts B and C. ONC's official website, 
                            <E T="03">HealthIT.gov,</E>
                             offers a variety of resources on the topic of Information Blocking, including fact sheets, recorded webinars, and frequently asked questions. To learn more, please visit: 
                            <E T="03">https://www.healthit.gov/topic/information-blocking/.</E>
                        </P>
                    </FTNT>
                    <P>This final rule adopts new and revised standards and requirements for the certification of health IT under the Program. For example, key provisions of this final rule implement the EHR Reporting Program through new Conditions and Maintenance of Certification requirements (referred herein as the Insights Condition) for developers of certified health IT, which will provide transparency into the use and benefits of certified health IT, with an initial focus on interoperability. This final rule revises several Program certification criteria, including criteria related to decision support, electronic case reporting, and standards-based application programming interfaces (APIs), as well as raises the baseline version of the USCDI from Version 1 to Version 3. The adoption of new and revised standards and criteria in this final rule will facilitate interoperability through standardized health information and functionality, which will lead to better care and health outcomes for patients, while reducing burden and costs. Finally, this rule continues to implement the provisions of the Cures Act to improve information sharing—and address information blocking—by providing refined definitions of statutory terms and further identifying practices that are reasonable and necessary and, therefore, do not constitute information blocking.</P>
                    <HD SOURCE="HD3">2. Administration Executive Orders</HD>
                    <P>
                        In addition to fulfilling the HITECH Act's and Cures Act's requirements described above, this final rule supports implementation of Executive Orders (E.O.) 13994, 13985, 14036, 14058, 14091, and 14110. The President issued E.O. 13994 on January 21, 2021, to ensure a data-driven response to COVID-19 and future high-consequence public health threats. The Cures Act and the information blocking provisions in the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program (85 FR 25642) (ONC Cures Act Final Rule) took critical steps to making data available across the healthcare system. Adoption of USCDI v3 in this rule facilitates the gathering, sharing, and publication of public health and emergency response data (
                        <E T="03">e.g.,</E>
                         the COVID-19 pandemic) by capturing and promoting the sharing of key data elements related to public health. The updates to API Conditions and Maintenance of Certification requirements, as discussed in section III.C.7, continue the implementation of ONC's statutory responsibilities and efforts to develop and standardize APIs and to help individuals and other authorized health care providers, including those engaged in public health, securely access EHI through the broader adoption of standardized APIs.
                        <E T="51">2 3</E>
                        <FTREF/>
                         Additionally, this final rule 
                        <PRTPAGE P="1194"/>
                        adopts consensus-based, industry-developed health IT standards for certified Health IT Modules to support electronic case reporting. As discussed in section III.C.4, among other benefits, electronic case reporting facilitates faster and more efficient disease tracking, prevention, and case management. It also provides more timely and complete data to public health agencies than manual or non-standardized reporting.
                    </P>
                    <FTNT>
                        <P>
                            <SU>2</SU>
                             ONC. (2022, October 18). 
                            <E T="03">API Resource Guide.</E>
                             ONC Health IT Certification Program API Resource Guide. Retrieved March 16, 2023, from 
                            <E T="03">https://onc-healthit.github.io/api-resource-guide/.</E>
                        </P>
                        <P>
                            <SU>3</SU>
                             Section 4002 of the 21st Century Cures Act (Cures Act) establishes a condition of certification that requires health IT developers to publish application programming interfaces (APIs) that allow “health information from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor 
                            <PRTPAGE/>
                            technology or standards, as provided for under applicable law.” The Cures Act's API Condition of Certification requirement also states that a developer must, through an API, “provide access to all data elements of a patient's electronic health record to the extent permissible under applicable privacy laws.” The API Conditions and Maintenance of Certification requirements and certification criteria are identified in 45 CFR part 170.
                        </P>
                    </FTNT>
                    <P>
                        We are also committed to advancing health equity, and this final rule is consistent with E.O. 13985 of January 20, 2021, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government,
                        <SU>4</SU>
                        <FTREF/>
                         and E.O. 14091 of February 16, 2023, Further Advancing Racial Equity and Support for Underserved Communities Through the Federal Government.
                        <SU>5</SU>
                        <FTREF/>
                         Section 1 of E.O. 13985 states that “the Federal Government should pursue a comprehensive approach to advancing equity for all, including people of color and others who have been historically underserved, marginalized, and adversely affected by persistent poverty and inequality.” Section 1 of E.O. 13985 also states that “because advancing equity requires a systematic approach to embedding fairness in decision-making processes, executive departments and agencies must recognize and work to redress inequities in their policies and programs that serve as barriers to equal opportunity.” As noted above, we have adopted USCDI v3 in this final rule to meet statutory responsibilities discussed in section II.A to improve the standardization of health information that is accessed, exchanged, and used within certified health IT. The USCDI v3 standard includes data elements on patient demographics (such as sexual orientation and gender identity) and social determinants of health (SDOH), as discussed in sections III.C.1 and III.C.8 of this final rule. These updates help capture more accurate and complete patient characteristics that are reflective of patient diversity and inclusion, which could potentially help data users address disparities in health outcomes for all patients, including those who may be marginalized and underrepresented. The use of USCDI v3 also supports data users' abilities to identify, assess, and analyze gaps in care, which could in turn be used to inform and address the quality of healthcare through interventions and strategies. This could lead to better patient care, experiences, and health outcomes.
                    </P>
                    <FTNT>
                        <P>
                            <SU>4</SU>
                             United States, Executive Office of the President [Joseph Biden]. Executive Order 13985: Advancing Racial Equity and Support for Underserved Communities Through the Federal Government. Jan 20, 2021. 86 FR 7009-7013, 
                            <E T="03">https://www.federalregister.gov/documents/2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>5</SU>
                             United States, Executive Office of the President [Joseph Biden]. Executive Order 14091: Further Advancing Racial Equity and Support for Underserved Communities Through the Federal Government. Feb 16, 2023. 88 FR 10825-10833, 
                            <E T="03">https://www.federalregister.gov/documents/2023/02/22/2023-03779/further-advancing-racial-equity-and-support-for-underserved-communities-through-the-federal.</E>
                        </P>
                    </FTNT>
                    <P>
                        Section 1 of E.O. 14091 also requires the Federal Government to “promote equity in science and root out bias in the design and use of new technologies, such as artificial intelligence.” Section 8 of E.O. 14091 requires agencies to “prevent and address discrimination and advance equity for all” and to “consider opportunities to prevent and remedy discrimination, including by protecting the public from algorithmic discrimination.” The E.O. states that the Federal Government shall continue to “advance equity in health, including mental and behavioral health and well-being.” We are committed to the concept of “health equity by design”,
                        <SU>6</SU>
                        <FTREF/>
                         in which health equity considerations are identified and incorporated from inception and throughout the technology design, build, and implementation process. We consider health equity by design to incorporate health equity strategies, tactics, and patterns as guiding principles for software and IT development, enforced by technical architecture, data, and information governance process, and built into the technology at every layer. In this final rule we apply the concept of health equity by design to bring transparency to the quality and performance of intelligence and machine learning-based decision support tools in healthcare. As discussed in section III.C.5, the “decision support intervention,” (DSI) certification criterion is supportive of the goals of E.O. 14091 and advances health equity by design by making it known to users of Health IT Modules certified to the DSI criterion whether patient demographic, SDOH, or health assessment data are used in DSIs. Other finalized policies: (1) establish a definition for algorithm-based and model-based “predictive” DSIs; (2) require Health IT Modules certified to the DSI criterion to enable users to access information about the design, development, training, and evaluation of Predictive DSIs, including descriptions of training data and information on whether the Predictive DSI was tested and evaluated for fairness; (3) require developers of certified health IT to apply risk management practices for all Predictive DSIs that are supplied by the developer of certified health IT as part of its Health IT Module; and (4) make summary information regarding these practices available publicly.
                    </P>
                    <FTNT>
                        <P>
                            <SU>6</SU>
                             
                            <E T="03">HealthIT.gov: Embracing Health Equity by Design. https://www.healthit.gov/buzz-blog/health-it/embracing-health-equity-by-design.</E>
                        </P>
                    </FTNT>
                    <P>
                        Additionally, the DSI certification criterion and surrounding transparency requirements are especially aligned with E.O. 14110, Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence, issued October 30, 2023.
                        <SU>7</SU>
                        <FTREF/>
                         The finalized DSI requirements will improve transparency, promote trustworthiness, and incentivize the development and wider use of fair, appropriate, valid, effective, and safe Predictive DSIs to aid decision-making in healthcare. The resulting information transparency increases public trust and confidence in these technologies so that the benefits of these technologies may expand in safer, more appropriate, and more equitable ways. This transparency also informs wider discussions, including those across industry, academia, and government, regarding how to evaluate and communicate performance related to Predictive DSIs, consistent with Section 8 of the E.O., “Protecting Consumers, Patients, Passengers, and Students.”
                    </P>
                    <FTNT>
                        <P>
                            <SU>7</SU>
                             United States, Executive Office of the President [Joseph Biden]. Executive Order 14110: Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence. Oct. 20, 2023. 88 FR 75191. 
                            <E T="03">https://www.federalregister.gov/documents/2023/11/01/2023-24283/safe-secure-and-trustworthy-development-and-use-of-artificial-intelligence.</E>
                        </P>
                    </FTNT>
                    <P>
                        The finalized DSI certification criterion also aligns with the public availability and transparency policy goals of the Office of Science and Technology Policy (OSTP) memorandum “Ensuring Free, Immediate, and Equitable Access to Federally Funded Research.” 
                        <SU>8</SU>
                        <FTREF/>
                         The memorandum provides policy guidance to federal agencies and departments to promote improved public access to and transparency of federally funded 
                        <PRTPAGE P="1195"/>
                        research. The finalized DSI certification criterion aligns with the goals of the memorandum by establishing requirements to make information available through § 170.315(b)(11)(iv), including information created through federally funded research and evaluations, that will enable users to determine if a Predictive DSI supplied by a health IT developer as part of its Health IT Module is acceptably fair, appropriate, valid, effective, and safe.
                    </P>
                    <FTNT>
                        <P>
                            <SU>8</SU>
                             Ensuring Free, Immediate, and Equitable Access to Federally Funded Research. Office of Science and Technology Policy (OSTP) (2022). 
                            <E T="03">https://www.whitehouse.gov/wp-content/uploads/2022/08/08-2022-OSTP-Public-access-Memo.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        President Biden's E.O. 14036, Promoting Competition in the American Economy, issued on July 9, 2021, established a whole-of-government effort to promote competition in the American economy and reaffirmed the policy stated in E.O. 13725 of April 15, 2016 (Steps to Increase Competition and Better Inform Consumers and Workers to Support Continued Growth of the American Economy).
                        <SU>9</SU>
                        <FTREF/>
                         This final rule fosters competition by advancing foundational standards for certified API technology, which enable—through applications (apps) and without special effort—improved legally permissible sharing of EHI among clinicians, patients, researchers, and others. As described in section III.C.7, competition is advanced through these improved API standards that can help individuals connect to their information and can help authorized health care providers, involved in the patient's care, securely access information. For example, these standards are designed to foster an ecosystem of new applications that can connect through the API technology to provide patients with improved electronic access to EHI.
                    </P>
                    <FTNT>
                        <P>
                            <SU>9</SU>
                             United States, Executive Office of the President [Joseph Biden]. Executive Order 14036: Promoting Competition in the American Economy. Jul 9, 2021. 86 FR 36987-36999, 
                            <E T="03">https://www.federalregister.gov/documents/2021/07/14/2021-15069/promoting-competition-in-the-american-economy.</E>
                        </P>
                    </FTNT>
                    <P>
                        Further, as described in section IV, this final rule provides enhancements to support information sharing under the information blocking regulations and promote innovation and competition, as well as address market consolidation. As we have noted, addressing information blocking is critical for promoting innovation and competition in health IT and for the delivery of healthcare services to individuals. In both the ONC Cures Act Proposed Rule (84 FR 7508) and Final Rule (85 FR 25790 through 25791), we discussed how the information blocking provisions provide a comprehensive response to the issues identified by empirical and economic research. This research suggested that information blocking may weaken competition, encourage consolidation, and create barriers to entry for developers of new and innovative applications and technologies that enable more effective uses of EHI to improve population health and the patient experience.
                        <SU>10</SU>
                        <FTREF/>
                         We explained that the information blocking provisions of the Public Health Service Act (PHSA) itself expressly addresses practices that impede innovation and advancements in EHI access, exchange, and use, including care delivery enabled by health IT (section 3022(a)(2)(C)(ii) of the PHSA). Actors subject to the information blocking provisions may,
                        <SU>11</SU>
                        <FTREF/>
                         among other practices, attempt to exploit their control over interoperability elements to create barriers to entry for competing technologies and services that offer greater value for health IT customers and users, provide new or improved capabilities, and enable more robust access, exchange, and use of EHI (85 FR 25820).
                        <SU>12</SU>
                        <FTREF/>
                         Information blocking may not only harm competition in health IT markets, but also in markets for healthcare services (85 FR 25820). In the ONC Cures Act Final Rule, we described practices that dominant market health care providers may leverage and use to control access and use of their technology, resulting in technical dependence and possibly leading to barriers to entry by would-be competitors, as well as making some market health care providers vulnerable to acquisition or inducement into arrangements that enhance the market power of incumbent health care providers to the detriment of consumers and purchasers of healthcare services (85 FR 25820). The implementation of the new information blocking provisions detailed in section IV of this final rule promote innovation, encourage market competition, and address consolidation in the interest of the patient to advance interoperability, improve transparency, and support the access, exchange, and use of EHI.
                    </P>
                    <FTNT>
                        <P>
                            <SU>10</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Martin Gaynor, Farzad Mostashari, and Paul B. Ginsberg, Making Health Care Markets Work: Competition Policy for Health Care, 16-17 (Apr. 2017), available at 
                            <E T="03">http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930;</E>
                             Diego A. Martinez et al., A Strategic Gaming Model For Health Information Exchange Markets, Health Care Mgmt. Science (Sept. 2016). (“[S]ome healthcare provider entities may be interfering with HIE across disparate and unaffiliated providers to gain market advantage.”) Niam Yaraghi, A Sustainable Business Model for Health Information Exchange Platforms: The Solution to Interoperability in Healthcare IT (2015), available at 
                            <E T="03">http://www.brookings.edu/research/papers/2015/01/30-sustainable-business-model-health-information-exchange-yaraghi;</E>
                             Thomas C. Tsai Ashish K. Jha, Hospital Consolidation, Competition, and Quality: Is Bigger Necessarily Better? 312 J. AM. MED. ASSOC. 29, 29 (2014).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>11</SU>
                             The information blocking regulations in 45 CFR part 171 apply to health care providers, health IT developers of certified health IT, and health information networks (HIN) and health information exchanges (HIE), as each is defined in 45 CFR 171.102. Any individual or entity that meets one of these definitions is an “actor” and subject to the information blocking regulation in 45 CFR part 171.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>12</SU>
                             See also Martin Gaynor, Farzad Mostashari, and Paul B. Ginsberg, Making Health Care Markets Work: Competition Policy for Health Care, 16-17 (Apr. 2017), available at 
                            <E T="03">http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930.</E>
                        </P>
                    </FTNT>
                    <P>
                        Lastly, in support of E.O. 14058, Transforming Federal Customer Experience and Service Delivery to Rebuild Trust in Government, issued on December 16, 2021, we are committed to advancing the equitable, inclusive, and effective delivery of services with a focus on the experience of individuals, health IT developers, and health care providers.
                        <SU>13</SU>
                        <FTREF/>
                         As required by section 4002 of the Cures Act and included in the ONC Cures Act Final Rule (85 FR 25717), we established certain Conditions and Maintenance of Certification requirements, which express initial and ongoing requirements for health IT developers and their certified Health IT Module(s) under the Program. This final rule implements the EHR Reporting Program Condition and Maintenance of Certification requirement outlined in the Cures Act by establishing—within the Program—a new Condition and Maintenance of Certification hereafter referred to as the “Insights Condition.” As discussed in section III.F, the implementation of the Insights Condition provides transparent reporting to address information gaps in the health IT marketplace and provides insights on the use of specific certified health IT functionalities. The implementation of this new Condition and Maintenance of Certification requirement will allow ONC to gain a better understanding of the use of health IT and provide ONC with information about consumers' experience with certified health IT.
                    </P>
                    <FTNT>
                        <P>
                            <SU>13</SU>
                             United States, Executive Office of the President [Joseph Biden]. Executive Order 14058: Transforming Federal Customer Experience and Service Delivery To Rebuild Trust in Government. Dec 13, 2021. 86 FR 71357-71366, 
                            <E T="03">https://www.federalregister.gov/documents/2021/12/16/2021-27380/transforming-federal-customer-experience-and-service-delivery-to-rebuild-trust-in-government.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">3. Federal Coordination</HD>
                    <P>
                        We strive to improve federal agency coordination. ONC works with the Centers for Medicare &amp; Medicaid Services (CMS) to ensure that the certification timelines we have established complement timelines for CMS programs that reference ONC regulations, such as the Medicare Promoting Interoperability Program and 
                        <PRTPAGE P="1196"/>
                        the Promoting Interoperability performance category of the Merit-based Incentive Payment System (MIPS). In the interest of clarity and cohesion among HHS components, we have aligned some of our compliance dates to the calendar year for consistency with calendar-year based performance periods in CMS programs when participants may be required to use updated certified health IT. We believe this approach reduces confusion for participants in these programs and better serves the public interest.
                    </P>
                    <HD SOURCE="HD2">B. Summary of Major Provisions</HD>
                    <HD SOURCE="HD3">1. ONC Health IT Certification Program Updates</HD>
                    <HD SOURCE="HD3">a. “The ONC Certification Criteria for Health IT” and Discontinuing Year Themed “Editions”</HD>
                    <P>We noted in the HTI-1 Proposed Rule that we no longer believed that it was helpful or necessary to maintain an “edition” naming convention or to adopt entirely new editions of certification criteria to encapsulate updates over time (88 FR 23750). Instead, we conveyed that there should be a single set of certification criteria, which would be updated in an incremental fashion in closer alignment to standards development cycles and regular health IT development timelines. In section III.A, we discuss our final policy to rename all certification criteria within the Program simply as “ONC Certification Criteria for Health IT.”</P>
                    <HD SOURCE="HD3">b. New and Revised Standards and Certification Criteria</HD>
                    <HD SOURCE="HD3">i. The United States Core Data for Interoperability Version 3 (USCDI v3)</HD>
                    <P>We noted in the HTI-1 Proposed Rule that because USCDI is the standard for data required to be accessible through certified health IT for numerous certification criteria, expanding the data elements and data classes included in USCDI increases the amount of data available to be used and exchanged for patient care (88 FR 23751). To expand standardized data reporting, we have finalized the proposal to codify USCDI v1 in § 170.213(a) and to add USCDI v3 to § 170.213 (to be codified as § 170.213(b)). We have incorporated USCDI v3 by reference in § 170.299 as of the effective date of this final rule. Lastly, we have finalized that the USCDI v1 (July 2020 Errata) in the USCDI standard in § 170.213(a) will expire on January 1, 2026. As codified in § 170.213, only USCDI v3 will be available in the Program as of January 1, 2026.</P>
                    <HD SOURCE="HD3">ii. C-CDA Companion Guide Updates</HD>
                    <P>As discussed in section III.C.2, we have finalized the adoption of the HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1—US Realm (C-CDA Companion Guide R4.1) in § 170.205(a)(6) because it is the only version that provides guidance and clarifications for specifying data in USCDI v3.</P>
                    <HD SOURCE="HD3">iii. “Minimum Standards” Code Sets Updates</HD>
                    <P>In the 2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications Final Rule (2015 Edition Final Rule), we established a policy of adopting newer versions of “minimum standards” code sets that frequently update (80 FR 62612). Adopting newer versions of these code sets enables improved interoperability and implementation of health IT with minimal additional burden (77 FR 54170). We discussed in the HTI-1 Proposed Rule that, if adopted, newer versions of these minimum standards code sets would serve as the baseline for certification, and developers of certified health IT would be able to use newer versions of these adopted standards on a voluntary basis (88 FR 23751). We have finalized, as discussed in section III.C.3, the adoption of the versions we had proposed of the following minimum standards code sets:</P>
                    <FP SOURCE="FP-1">• § 170.207(a)—Problems</FP>
                    <FP SOURCE="FP-1">• § 170.207(c)—Laboratory tests</FP>
                    <FP SOURCE="FP-1">• § 170.207(d)—Medications</FP>
                    <FP SOURCE="FP-1">• § 170.207(e)—Immunizations</FP>
                    <FP SOURCE="FP-1">• § 170.207(f)—Race and ethnicity</FP>
                    <FP SOURCE="FP-1">• § 170.207(m)—Numerical references</FP>
                    <FP SOURCE="FP-1">• § 170.207(n)—Sex</FP>
                    <FP SOURCE="FP-1">• § 170.207(o)—Sexual orientation and gender information</FP>
                    <FP SOURCE="FP-1">• § 170.207(p)—Social, psychological, and behavioral data</FP>
                    <FP SOURCE="FP-1">• § 170.207(r)—Provider type</FP>
                    <FP SOURCE="FP-1">• § 170.207(s)—Patient insurance</FP>
                    <P>
                        In addition to the finalized adoption of the minimum standards code sets listed above, we have finalized proposed updates to certification criteria that reference those minimum standards. These criteria include § 170.315(a)(5)(i)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ), (a)(5)(i)(C) through (E), (a)(12), (b)(1)(iii)(B)(
                        <E T="03">2</E>
                        ), (b)(1)(iii)(G)(
                        <E T="03">3</E>
                        ), (b)(6)(ii)(B)(
                        <E T="03">2</E>
                        ), (c)(4)(iii)(C), (c)(4)(iii)(E), (c)(4)(iii)(G) through (I), (f)(1)(i)(B) and (C), (f)(3)(ii), and (f)(4)(ii).
                    </P>
                    <P>We have finalized the proposal to change the heading of § 170.207(o) to “sexual orientation and gender information” to acknowledge that § 170.207(o) includes standard code sets to support gender-related data items in addition to standard code sets to support sexual orientation.</P>
                    <HD SOURCE="HD3">iv. Electronic Case Reporting</HD>
                    <P>As discussed in section III.C.4 of this final rule, we have finalized the revisions to the “transmission to public health agencies—electronic case reporting” criterion in § 170.315(f)(5) to adopt consensus-based, industry-developed electronic standards and implementation guides (IGs) to replace all functional, descriptive requirements in the present criterion in § 170.315(f)(5). These standards will support the following requirements for Health IT Modules certified to § 170.315(f)(5): (i) create a case report for electronic transmission; (ii) consume and process a case report response; and (iii) consume and process electronic case reporting trigger codes. We note that these electronic standards are standards-based representations of the functional requirements described in the existing criterion in § 170.315(f)(5) as described in section III.C.4 of this preamble.</P>
                    <HD SOURCE="HD3">v. Decision Support Interventions and Predictive Models</HD>
                    <P>As discussed in section III.C.5 of this final rule, we have finalized the adoption of the certification criterion, “decision support interventions (DSI)” in § 170.315(b)(11). The DSI criterion is a revised certification criterion, serving both an iterative update and replacement criterion for the “clinical decision support (CDS)” certification criterion in § 170.315(a)(9) (88 FR 23751). The DSI criterion, as finalized, ensures that Health IT Modules certified to § 170.315(b)(11) reflect an array of contemporary functionalities, support data elements important to health equity, and enable the transparent use of predictive models and algorithms to aid decision-making in healthcare.</P>
                    <P>
                        We have adopted a new definition for Predictive Decision Support Intervention, (also referred to hereafter as Predictive DSI) in § 170.102, and we have finalized that Health IT Modules certified to § 170.315(b)(11) must enable a limited set of identified users to select (
                        <E T="03">i.e.,</E>
                         activate) evidence-based and Predictive DSIs, as described in § 170.315(b)(11)(iii). Additionally, we have finalized that Health IT Modules certified to § 170.315(b)(11) must support “source attributes”—categories of technical performance and quality information—for both evidence-based 
                        <PRTPAGE P="1197"/>
                        and Predictive DSIs in § 170.315(b)(11)(iv).
                    </P>
                    <P>
                        We have 
                        <E T="03">not</E>
                         finalized proposed requirements that Health IT Modules clearly indicate when source attributes from 
                        <E T="03">other parties</E>
                         are unavailable. Rather, we have finalized that Health IT Modules certified to § 170.315(b)(11) must enable a limited set of identified users to access complete and up-to-date descriptions of all source attributes related to evidence-based DSIs and Predictive DSIs that are supplied by the developer of certified health IT as part of their Health IT Module, as described in § 170.315(b)(11)(v)(A). Moreover, we have finalized in § 170.315(b)(11)(v)(B) requirements that Health IT Modules certified to § 170.315(b)(11) must enable a limited set of identified users to record and change source attributes listed in paragraphs § 170.315(b)(11)(iv)(A) and (B).
                    </P>
                    <P>We have also finalized in § 170.315(b)(11)(vi) that intervention risk management (IRM) practices must be applied for each Predictive DSI supplied by the health IT developer as part of its Health IT Module, including requirements to subject Predictive DSIs to risk analysis and risk mitigation related to validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy. We note that for governance practices, we have finalized in § 170.315(b)(11)(vi)(C) requirements for Health IT Modules to be subject to policies and implemented controls for governance, including how data are acquired, managed, and used. Consistent with the other IRM practices, these policies and implemented controls must be applied for all Predictive DSIs supplied by the health IT developer as part of its Health IT Module.</P>
                    <P>Additionally, in consideration of comments received and the scope reductions we have made to this final certification criterion, we determined that a supportive Maintenance of Certification requirement as part of the Assurances Condition of Certification is necessary to implement our policy objectives and proposals fully. Specifically, we have included in this final rule a Maintenance of Certification requirement at 45 CFR 170.402(b)(4) that reinforces a health IT developer's ongoing responsibility to review and update, as necessary, source attribute information in § 170.315(b)(11)(v)(A) and (B), risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi). We have finalized in § 170.402(b)(4) that developers with products certified to § 170.315(b)(11) will need to comply with this Maintenance of Certification requirement starting January 1, 2025.</P>
                    <P>
                        Finally, we have finalized our proposals to facilitate this transition from one version of the criterion to the other by updating the 2015 Edition Base EHR definition in § 170.102,
                        <SU>14</SU>
                        <FTREF/>
                         which is being replaced with a definition of Base EHR, to include an option for a Health IT Module to meet the definition by either being certified to the existing CDS version of the certification criterion in § 170.315(a)(9), or being certified to the revised DSI criterion in § 170.315(b)(11), for the period up to, and including, December 31, 2024. On and after January 1, 2025, only the DSI criterion in § 170.315(b)(11) will be included in the Base EHR definition and the adoption of the criterion in § 170.315(a)(9) will expire on January 1, 2025. We discuss in section III.C.5.b of this preamble policies that would constitute changes to the CDS criterion, as the new DSI criterion.
                    </P>
                    <FTNT>
                        <P>
                            <SU>14</SU>
                             In section III.C.5.a.i., we discuss finalizing our proposal to adopt a definition of “Base EHR” and remove the prior definition of “2015 Edition Base EHR.”
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">vi. Synchronized Clocks Standard</HD>
                    <P>We have finalized, as discussed in section III.C.6, the removal of the current named specification for clock synchronization, which is Network Time Protocol (NTP v4 of RFC 5905), in § 170.210(g). Additionally, we have finalized the requirement for any network time protocol (NTP) standard to be used that can ensure a system clock has been synchronized and meets time accuracy requirements.</P>
                    <HD SOURCE="HD3">vii. Standardized API for Patient and Population Services</HD>
                    <P>We have finalized, as discussed in section III.C.7, the proposed revisions to the “standardized API for patient and population services” certification criterion in § 170.315(g)(10). We have finalized the requirement that a certified Health IT Module's authorization server issues a refresh token according to the implementation specification adopted in § 170.215(c).</P>
                    <P>We have also finalized the proposed revisions in § 170.315(g)(10)(vi) to specify that Health IT Modules presented for certification that allow short-lived access tokens to expire, in lieu of immediate access token revocation, must have such access tokens expire within one hour of the request. This revised requirement aligns with industry standard practice for short-lived access tokens, provides clarity and consistent expectations that developers revoke access or expire access privileges within one hour of a request, and offers patients an assurance that an application's access to their data will be revoked or expired within one hour of a request.</P>
                    <P>We have also adopted the HL7® FHIR® US Core Implementation Guide (IG) STU version 6.1.0 (FHIR US Core 6.1.0) in § 170.215(b)(1)(ii). This version of the US Core IG provides the latest consensus-based capabilities aligned with USCDI v3 data elements for FHIR APIs.</P>
                    <P>Additionally, we have finalized the proposal to amend the API Condition and Maintenance of Certification requirements by adding the requirement that Certified API Developers with patient-facing apps must meet the publication requirements associated with service base URLs according to a specified format.</P>
                    <P>We have adopted the Substitutable Medical Applications, Reusable Technologies (SMART) App Launch Implementation Guide Release 2.0.0 (SMART v2 Guide) in § 170.215(c)(2), which replaces the SMART Application Launch Framework Implementation Guide Release 1.0.0 (SMART v1 Guide) as the standard in § 170.215(a)(3) (finalized in this rule as § 170.215(c)(1)). Adoption of this standard impacts the certification criterion in § 170.315(g)(10) in several subparagraphs. The SMART v2 Guide builds on the features of the SMART v1 Guide by including new features and technical revisions based on industry consensus, including features that reflect security best practices. The SMART v1 Guide will continue to be available as a standard for use in the Program through December 31, 2025. Beginning January 1, 2026, the SMART v2 Guide will be the only version of the IG available for use in the Program.</P>
                    <HD SOURCE="HD3">viii. Patient Demographics and Observations Certification Criterion in § 170.315(a)(5)</HD>
                    <P>
                        We have finalized, as discussed in section III.C.1 of this final rule, the adoption of USCDI v3, which includes certain data elements, namely Sex, Sexual Orientation, and Gender Identity, that are also data elements in § 170.315(a)(5). As discussed in section III.C.8 of this preamble, to ensure consistency, we have finalized the name change of the certification criterion in § 170.315(a)(5) from “demographics” to “patient demographics and observations.” Additionally, to ensure consistent capture of these data elements across health IT, we carry these changes into their respective data elements in § 170.315(a)(5), as discussed in section III.C.8.
                        <PRTPAGE P="1198"/>
                    </P>
                    <P>We have finalized the replacement of the specific concepts referenced in § 170.315(a)(5)(i)(D) and (E), Sexual Orientation and Gender Identity, respectively, with the Systematized Nomenclature of Medicine Clinical Terms U.S. Edition (SNOMED CT®) code set, as referenced in the standard in § 170.207(o)(3). We have 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.</P>
                    <P>We have finalized the addition of Sex Parameter for Clinical Use as a new data element in § 170.315(a)(5)(i)(F). As discussed in section III.C.1 of this final rule, we proposed Sex for Clinical Use in the HTI-1 Proposed Rule and have revised the title of Sex for Clinical Use to instead be Sex Parameter for Clinical Use (SPCU) to align with changes made by the HL7 Gender Harmony Project and updated the title in § 170.315(a)(5)(i)(F). The data element definition did not change. Additionally, we have finalized new data elements—Name to Use in § 170.315(a)(5)(i)(G) and Pronouns in § 170.315(a)(5)(i)(H)—to facilitate data capture that supports providers' ability to provide culturally competent care for their patients.</P>
                    <HD SOURCE="HD3">ix. Updates to Transitions of Care Certification Criterion in § 170.315(b)(1)</HD>
                    <P>We have finalized, as discussed in section III.C.9, the proposed updates to the “transitions of care” certification criterion (§ 170.315(b)(1)) to align it with our adoption of USCDI v3 in § 170.213(b). This change ensures that Health IT Modules certified to § 170.315(b)(1) are capable of accessing, exchanging, and using USCDI data elements referenced in the standards in § 170.213.</P>
                    <HD SOURCE="HD3">x. Patient Right To Request a Restriction on Use or Disclosure</HD>
                    <P>
                        We stated in the HTI-1 Proposed Rule that we believed that individuals should be provided a reasonable opportunity and technical capability to make informed decisions about the collection, use, and disclosure of their electronic health information (88 FR 23753). The Health Insurance Portability and Accountability Act (HIPAA) 
                        <SU>15</SU>
                        <FTREF/>
                         Privacy Rule 
                        <SU>16</SU>
                        <FTREF/>
                         provides individuals with several legal, enforceable rights that empower them to manage their health information. We made several proposals in support of the HIPAA Privacy Rule's individual right to request restriction of certain uses and disclosures of their protected health information 
                        <SU>17</SU>
                        <FTREF/>
                         (PHI) (
                        <E T="03">see also</E>
                         45 CFR 154.522(a)). In this final rule, we have finalized a requirement for Health IT Modules certified to the “view, download, and transmit to a 3rd party,” certification criterion in § 170.315(e)(1) to support an “internet-based method” for a patient to request a restriction as proposed. Based on the feedback received from numerous interested parties, we have decided not to finalize the remainder of our proposals for patient requested restrictions at this time. We will continue to monitor standards development efforts in this space.
                    </P>
                    <FTNT>
                        <P>
                            <SU>15</SU>
                             Public Law 104-191,110 Stat. 1936 (August 21, 1996), codified at 42 U.S.C. 1320d-1320d8.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>16</SU>
                             45 CFR part 160 and subparts A and E of part 164.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>17</SU>
                             45 CFR 160.103 (definition of “Protected health information”).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">xi. Requirement for Health IT Developers To Update Their Previously Certified Health IT</HD>
                    <P>We have finalized our proposal to add text to the introductory text in § 170.315 stating that health IT developers participating in the Program must update their certified Health IT Modules and provide that updated certified health IT to customers in accordance with the timelines defined for a specific criterion or standard included in § 170.315. More specifically, we have finalized, as discussed in section III.C.11, that health IT developers with health IT certified to any of the certification criteria in § 170.315 will need to update their previously certified Health IT Modules to be compliant with any revised certification criterion adopted in § 170.315, including any new standards adopted in 45 CFR part 170 subpart B and capabilities included in the revised certification criterion. We have further finalized the requirement that health IT developers will also need to provide the updated health IT to customers of the previously certified health IT according to the dates established for that criterion and any applicable standards.</P>
                    <HD SOURCE="HD3">2. Assurances Condition and Maintenance of Certification Requirements</HD>
                    <P>We have finalized, as discussed in section III.D, additional Assurances Condition and Maintenance of Certification requirements. We have finalized as a Condition of Certification that a health IT developer must provide an assurance that it will not interfere with a customer's timely access to interoperable health IT certified under the Program. To support this assurance, we have finalized two accompanying Maintenance of Certification requirements. We have finalized that a health IT developer must update a Health IT Module, once certified to a certification criterion adopted in § 170.315, to all applicable revised certification criteria, including the most recently adopted capabilities and standards included in the revised certification criterion. We have also finalized that a health IT developer must provide all Health IT Modules certified to a revised certification criterion to its customers of such certified health IT. In response to comments and to provide regulatory clarity, we have revised the separate “timely access” or “timeliness” requirements for each of the two proposed Maintenance of Certification requirements. Rather than relying on independent timeliness requirements for previously certified health IT, the maintenance requirements now cross-reference timeframes specified in 45 CFR part 170, while still maintaining the proposed minimum 12-month timeframe for new customers.</P>
                    <HD SOURCE="HD3">3. Real World Testing—Inherited Certified Status</HD>
                    <P>
                        Section 4002(a) of the Cures Act added a new Condition and Maintenance of Certification requirement that health IT developers must successfully test the real-world use of health IT for interoperability in the type(s) of setting(s) in which such technology would be marketed. Many health IT developers update their certified Health IT Module(s) on a regular basis, leveraging the flexibility provided through ONC's Inherited Certified Status (ICS).
                        <SU>18</SU>
                        <FTREF/>
                         Because of the way that ONC issues certification identifiers, this updating can cause an existing certified Health IT Module to be recognized as new within the Program. Regular updating, especially on a frequent basis (such as quarterly or semi-annually), creates an anomaly that could result in existing certified Health IT Modules being inadvertently excluded from the real world testing reporting requirements (88 FR 23753).
                    </P>
                    <FTNT>
                        <P>
                            <SU>18</SU>
                             See 2015 Edition Cures Update Fact Sheet: 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2022-03/Cures-Update-Fact-Sheet.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        To ensure that all developers continue to test the real-world use of their technology as required, we have finalized, as discussed in section III.E, 
                        <PRTPAGE P="1199"/>
                        the proposal to eliminate this anomaly by requiring health IT developers to include in their real world testing results report the newer version of those certified Health IT Module(s) that are updated using ICS after August 31 of the year in which the plan is submitted. This will ensure that health IT developers fully test all applicable certified Health IT Module(s) as part of their real world testing requirements.
                    </P>
                    <HD SOURCE="HD3">4. Insights Condition and Maintenance of Certification</HD>
                    <P>The Cures Act specified requirements in section 4002(c) to establish an EHR Reporting Program to provide reporting on certified health IT in the categories of interoperability, usability and user-centered design, security, conformance to certification testing, and other categories as appropriate to measure the performance of EHR technology. The Cures Act also specified, in text added at section 3009A(b) of the Public Health Service Act, that a health IT developer be required, as a Condition and Maintenance of Certification requirement under the ONC Health IT Certification Program, to submit responses to reporting criteria in accordance with the EHR Reporting Program established with respect to all certified technology offered by such developer. For clarity, we refer to the Condition and Maintenance of Certification associated with the “EHR Reporting Program” as the “Insights Condition and Maintenance of Certification” (also referred to as the “Insights Condition”) throughout this final rule. We believe this descriptive name captures the essence of this requirement and will help avoid confusion that might occur through use of the term “EHR Reporting Program.”</P>
                    <P>In section III.F, we have adopted seven reporting measures for developers of certified health IT that focus initially on the interoperability category, emphasizing four areas of interoperability: (1) individuals' access to electronic health information; (2) public health information exchange; (3) clinical care information exchange; and (4) standards adoption and conformance. Through this first set of finalized measures, we intend to provide insights on the interoperability category specified in the Cures Act. We intend to explore the other Cures Act categories (security, usability and user-centered design, conformance to certification testing, and other categories to measure the performance of EHR technology) in future years.</P>
                    <P>We have also finalized, as discussed in section III.F, the implementation of the Insights Condition requirements in § 170.407 in three phases over three years, where health IT developers to which the requirements apply, will be required to report on some of the measures earlier than others. For each final measure, we have included information on the rationale for adopting the measure, the final metrics, and other key topics. The Insights Condition will provide transparent reporting, address information gaps in the health IT marketplace, and provide insights on the use of health IT.</P>
                    <HD SOURCE="HD3">5. Information Blocking Enhancements</HD>
                    <P>
                        As discussed in section IV.B.1 of this preamble, we have finalized a definition of “offer health information technology” or “offer health IT” for purposes of the information blocking regulations in 45 CFR part 171. This definition of “offer health IT,” as finalized in § 171.102, narrows the applicability of the “health IT developer of certified health IT” definition in 45 CFR 171.102. The definition of “offer health IT,” finalized in 45 CFR 171.102, will generally continue to include holding out for sale, selling, or otherwise supplying certified health IT to others on commercial or other terms. However, our finalized definition of “offer health IT” explicitly excludes certain activities and arrangements. First, the “offer health IT” definition excludes making available funding to obtain or maintain certified health IT, provided the funding is made available without condition(s) limiting the interoperability, or use of the technology to access, exchange or use electronic health information for any lawful purpose (
                        <E T="03">see</E>
                         paragraph (1) of the offer health IT definition). Second, the finalized “offer health IT” definition also explicitly codifies that health care providers or other health IT users do not “offer health IT” when they engage in certain health IT implementation and use activities, regardless of whether they obtain that health IT from a commercial developer or a reseller or develop it themselves (
                        <E T="03">see</E>
                         paragraph (2) of the offer health IT definition).
                    </P>
                    <P>
                        We have also finalized (in paragraph (3) of the “offer health IT” definition) an exclusion from the “offer health IT” definition that applies to certain consulting and legal services. This consulting and legal services exclusion (
                        <E T="03">see</E>
                         subparagraph (3)(iii)) encompasses supplying health IT in complement to the other items, supplies, facilities, and services that a consultant handles for a clinician practice or other health care provider in a comprehensive (“turn key”) package of services for administrative or operational management (
                        <E T="03">see</E>
                         section IV.B.1.c.iii of this preamble). The consulting and legal services exclusion from the “offer health IT” definition also encompasses assistance by health IT consultants with the selection, implementation, and use of health IT as specified in subparagraph (3)(ii) and legal services furnished by outside counsel as specified in subparagraph (3)(i).
                    </P>
                    <P>As discussed in section IV.B.2, we have modified the “health IT developer of certified health IT” definition so that it is clear that health care providers who self-develop certified health IT will continue to be excluded from this definition if they do not engage in activities falling within the “offer health IT” definition. The updated § 171.102 health IT developer of certified health IT definition we have finalized represents a change from prior policy to the extent that a health care provider that is a self-developer would not meet the definition of “health IT developer of certified health IT” if they supply certified health IT to one or more other health care provider(s) under a comprehensive and predominantly non-health IT administrative or operations management services arrangement consistent with subparagraph (3)(iii) (under the consulting and legal services exclusion from the 45 CFR 171.102 “offer health IT” definition). Previously, health care providers who self-developed certified health IT were excluded from the 45 CFR 171.102 “health IT developer of certified health IT” definition if they self-developed the Health IT Module(s) for their “own use” (85 FR 25799 and 25956).</P>
                    <P>
                        We have finalized revisions to the text of § 171.103, which defines “information blocking” for purposes of 45 CFR part 171, to remove paragraph (b) that established a period of time during which electronic health information (EHI) for purposes of the information blocking provision (§ 171.103) was limited to a subset of EHI that was identified by the data elements represented in the USCDI standard adopted in § 170.213. As established in the ONC Cures Act Final Rule (85 FR 25793, 85 FR 25876, and 85 FR 25956), that period of time ended on May 2, 2022. The end date of that period of time was extended to October 5, 2022, in the subsequent interim final rule with comment titled “Information Blocking and the ONC Health IT Certification Program: Extension of the Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency” (85 FR 70064). On and after October 6, 2022, the scope of EHI for purposes of the “information blocking” definition (§ 171.103) is EHI as defined in § 171.102 (88 FR 23754, 
                        <E T="03">see also</E>
                         85 FR 25793, 25876, 70069, and 
                        <PRTPAGE P="1200"/>
                        70085). October 5, 2022, has passed. Therefore, the paragraph (which had been designated paragraph (b), as codified) limiting the “information blocking” definition to the subset of EHI for the specified time period is no longer needed. We have re-designated remaining paragraphs of § 171.103 as discussed in section IV.B.3 and as shown in updated text we have finalized in § 171.103 (
                        <E T="03">see</E>
                         Regulation Text, 
                        <E T="03">see also</E>
                         discussion in section IV.B.3).
                    </P>
                    <P>
                        We note that in the HTI-1 Proposed Rule we did not propose to change the scope of EHI for purposes of the information blocking definition (88 FR 23754). We simply proposed to update the CFR text to remove paragraph (b) from § 171.103 that had temporarily—until October 5, 2022—limited the scope of the information blocking definition to the subset of EHI represented by USCDI v1 (88 FR 23864 and 23916). Similarly, because we included the same time period in reference to the scope of EHI in two paragraphs of the Content and Manner Exception (§ 171.301(a)(1) and (2)), we proposed to revise § 171.301 to remove from the regulatory text the existing § 171.301(a)(1) and (2) as no longer necessary (88 FR 23754). We have finalized the revisions to § 171.301 to remove the regulatory text in subparagraphs (a)(1) and (2) as no longer necessary and rename § 171.301 the Manner Exception. We have finalized the redesignation of the paragraphs now codified within § 171.301, so that different paragraphs are now designated (a)(1) and (2) rather than the paragraphs we have removed as no longer necessary (
                        <E T="03">see</E>
                         discussion in sections IV.B.3 and IV.C.2, 
                        <E T="03">see also</E>
                         Regulation Text for revised and redesignated paragraphs of § 171.301).
                    </P>
                    <P>
                        As explained in section IV.C.1, we have finalized revisions to the Infeasibility Exception codified in 45 CFR 171.204 both by adding two new conditions and by revising one existing condition for improved clarity. First, we have finalized revisions to the 
                        <E T="03">uncontrollable events</E>
                         condition in § 171.204(a)(1) to further clarify when an actor's practice meets the 
                        <E T="03">uncontrollable events</E>
                         condition. Our finalized revision to § 171.204(a), the 
                        <E T="03">uncontrollable events</E>
                         condition of the Infeasibility Exception, is discussed in Section IV.C.1.a. Second, we have added two new conditions to be codified as subparagraphs (a)(3) and (a)(4) and have, therefore, redesignated the 
                        <E T="03">infeasible under the circumstances</E>
                         condition as subparagraph (a)(5). The 
                        <E T="03">infeasible under the circumstances</E>
                         condition was previously designated as subparagraph (a)(3) of § 171.204.
                    </P>
                    <P>
                        The first new infeasibility condition in § 171.204(a)(3) (discussed in Section IV.C.1.b) will apply to an actor's practice of denying a third party's request to enable use of EHI in order to modify EHI, including, but not limited to, creation and deletion functionality, provided the request is not from a health care provider requesting such use from an actor that is their business associate.
                        <SU>19</SU>
                        <FTREF/>
                         In support of this new condition, we have finalized as proposed a definition of “business associate” in § 171.102. That definition is, by cross-reference to 45 CFR 160.103, the HIPAA Privacy Rule's definition of “business associate.”
                    </P>
                    <FTNT>
                        <P>
                            <SU>19</SU>
                             See definition of “business associate” at 45 CFR 160.103. Business associates include a subcontractor that creates, receives, maintains, or transmits protected health information on behalf of the business associate.
                        </P>
                    </FTNT>
                    <P>The second new infeasibility condition in § 171.204(a)(4), discussed in Section IV.C.1.c, will apply where an actor has exhausted the Manner Exception in § 171.301, including offering at least two alternative manners in accordance with § 171.301(b), including one manner that uses either technology certified to standard(s) adopted in 45 CFR part 170 that is specified by the requestor (§ 171.301(b)(1)(i)) or published content and transport standards consistent with § 171.301(b)(1)(ii). The actor cannot meet this new condition if the actor currently provides a substantial number of individuals or entities similarly situated to the requestor with the same requested access, exchange, or use of the requested EHI.</P>
                    <P>
                        As discussed in section IV.C.3, we have finalized a new subpart D under part 171 for information blocking exceptions that involve practices related to actors' participation in the Trusted Exchange Framework and Common Agreement (TEFCA
                        <SU>SM</SU>
                        ). In this new subpart D, we have established a standalone TEFCA Manner Exception, in § 171.403, that is based on a proposed 
                        <E T="03">TEFCA manner</E>
                         condition of the Manner Exception that was included in the HTI-1 Proposed Rule. The new exception provides that an actor's practice of not fulfilling a request to access, exchange, or use EHI in any alternative manner besides via TEFCA will not be considered information blocking when the practice follows certain conditions, which are discussed in more detail in section IV.C.3. Both the actor and requestor must be part of TEFCA, and the requestor must be able to access, exchange, or use the requested EHI via TEFCA. In consideration of comments and our stated policy goals, any fees or license agreements 
                        <E T="03">must</E>
                         satisfy the Fees (§ 171.302) and Licensing (§ 171.303) exceptions, which is counter to our initial proposed position. Further, in consideration of our stated policy goals and comments we received, the exception is 
                        <E T="03">not</E>
                         available when the requestor has requested access, exchange, or use via FHIR-based APIs.
                    </P>
                    <P>In section IV.D, we discuss information blocking requests for information that we included in section IV.C of the HTI-1 Proposed Rule (88 FR 23873).</P>
                    <HD SOURCE="HD2">C. Costs and Benefits</HD>
                    <P>
                        Executive Orders 128660 
                        <SU>20</SU>
                        <FTREF/>
                         and 13563 
                        <SU>21</SU>
                        <FTREF/>
                         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 
                        <SU>22</SU>
                        <FTREF/>
                         entitled “Modernizing Regulatory Review” (hereinafter, the Modernizing E.O.) amends section 3(f) 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 that may: (1) have an annual effect on the economy of $200 million or more (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) create a serious inconsistency or otherwise interfere with an action taken or planned by another agency; (3) materially alter the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raise 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. OMB has determined that this final rule is a significant regulatory action, as the potential economic 
                        <PRTPAGE P="1201"/>
                        impacts associated with this final rule could be greater than $200 million per year. Accordingly, we have prepared a Regulatory Impact Analysis (RIA) that, to the best of our ability, presents the costs and benefits of this final rule. We have estimated the potential monetary costs and benefits of this final rule for the health IT community, including costs and benefits as they relate to health IT developers, health care providers, patients, and the Federal Government (
                        <E T="03">i.e.,</E>
                         ONC), and have broken those costs and benefits out by section. In accordance with E.O. 12866, we have included the RIA summary table as Table 37.
                    </P>
                    <FTNT>
                        <P>
                            <SU>20</SU>
                             
                            <E T="03">https://www.archives.gov/files/federal-register/executive-orders/pdf/12866.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>21</SU>
                             
                            <E T="03">https://obamawhitehouse.archives.gov/the-press-office/2011/01/18/executive-order-13563-improving-regulation-and-regulatory-review</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>22</SU>
                             
                            <E T="03">https://www.whitehouse.gov/briefing-room/presidential-actions/2023/04/06/executive-order-on-modernizing-regulatory-review/.</E>
                        </P>
                    </FTNT>
                    <P>
                        We note that we have rounded all estimates to the nearest dollar and that all estimates are expressed in 2022 dollars as it is the most recent data available to address all cost and benefit estimates consistently. The wages used to derive the cost estimates are from the May 2022 National Occupational Employment and Wage Estimates reported by the U.S. Bureau of Labor Statistics.
                        <SU>23</SU>
                        <FTREF/>
                         We also note that estimates presented in the following “Employee Assumptions and Hourly Wage,” “Quantifying the Estimated Number of Health IT Developers and Products,” and “Number of End Users that Might Be Impacted by ONC's Proposed Regulations” sections are used throughout the RIA.
                    </P>
                    <FTNT>
                        <P>
                            <SU>23</SU>
                             May 2021 National Occupational Employment and Wage Estimates, United States. U.S. Bureau of Labor Statistics. 
                            <E T="03">https://www.bls.gov/oes/current/oes_nat.htm.</E>
                        </P>
                    </FTNT>
                    <P>We estimate that the total annual cost for this final rule for the first year after it is finalized (including one-time costs), based on the cost estimates outlined throughout the RIA, would result in $437 million. The total undiscounted perpetual cost over a 10-year period for this final rule (starting in year three), would result in $477 million. We estimate the total costs to health IT developers to be $914 million and estimate the government (ONC) costs to be between $56,800 to $113,600.</P>
                    <P>We estimate the total annual benefit for this final rule would be on average $1.0 billion. We estimate the total undiscounted perpetual annual net benefit for this final rule (starting in year three), would be $124 million.</P>
                    <HD SOURCE="HD1">II. Background</HD>
                    <HD SOURCE="HD2">A. Statutory Basis</HD>
                    <P>The Health Information Technology for Economic and Clinical Health Act (HITECH Act), Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act amended the Public Health Service Act (PHSA) and created “Title XXX—Health Information Technology and Quality” (Title XXX) to improve healthcare quality, safety, and efficiency through the promotion of health IT and electronic health information (EHI) exchange.</P>
                    <P>The 21st Century Cures Act, Public Law 114-255 (Cures Act), was enacted on December 13, 2016, to accelerate the discovery, development, and delivery of 21st century cures, and for other purposes. The Cures Act, through Title IV—Delivery, amended the HITECH Act by modifying or adding certain provisions to the PHSA relating to health IT.</P>
                    <P>Section 119 of Title I, Division CC of the Consolidated Appropriations Act, 2021, Public Law 116-260 (CAA), enacted on December 27, 2020, requires prescription drug plan (PDP) sponsors to implement one or more real-time benefit tools (RTBTs) that meet the requirements described in the statute, after the Secretary has adopted a standard for RTBTs and at a time determined appropriate by the Secretary. For purposes of the requirement to implement a real-time benefit tool in section 1860D-4(o)(1) of the Social Security Act, described above, the CAA provides that one of the requirements for an RTBT is that it can integrate with electronic prescribing and EHR systems of prescribing healthcare professionals for the transmission of formulary and benefit information in real time to such professionals. The statute requires incorporation of RTBTs within both the Medicare Part D prescription drug program and the Program. Specifically, the law amends the definition of a “qualified electronic health record” (qualified EHR) in section 3000(13) of the PHSA to require that a qualified EHR must include (or be capable of including) an RTBT.</P>
                    <HD SOURCE="HD3">1. Standards, Implementation Specifications, and Certification Criteria</HD>
                    <P>The HITECH Act established two Federal advisory committees, the Health IT Policy Committee (HITPC) and the Health IT Standards Committee (HITSC). Each was responsible for advising the National Coordinator for Health Information Technology (National Coordinator) on different aspects of standards, implementation specifications, and certification criteria.</P>
                    <P>
                        Section 4003(e) of the Cures Act amended sections 3002 and 3003 of the PHSA by replacing, in an amended section 3002, the HITPC and HITSC with one committee named the Health Information Technology Advisory Committee (Health IT Advisory Committee or HITAC). Section 3002(a) of the PHSA, as added by the Cures Act, establishes that the HITAC recommends to the National Coordinator policies and standards, implementation specifications, and certification criteria, relating to the implementation of a health information technology infrastructure, nationally and locally, that advances the electronic access, exchange, and use of health information. Further described in section 3002(b)(1) of the PHSA, this includes recommending to the National Coordinator a policy framework to advance interoperable health information technology infrastructure, updating recommendations to the policy framework, and making new recommendations, as appropriate. Section 3002(b)(2)(A) of the PHSA specifies that in general, the HITAC shall recommend to the National Coordinator for purposes of adoption under section 3004, standards, implementation specifications, and certification criteria and an order of priority for the development, harmonization, and recognition of such standards, specifications, and certification criteria. Like the process previously required of the former HITPC and HITSC, section 3002(b)(5) of the PHSA requires the HITAC to develop a schedule, updated annually, for the assessment of policy recommendations, which the Secretary publishes in the 
                        <E T="04">Federal Register</E>
                        .
                    </P>
                    <P>
                        Section 3004 of the PHSA establishes a process for the adoption of health IT standards, implementation specifications, and certification criteria and authorizes the Secretary to adopt such standards, implementation specifications, and certification criteria. As specified in section 3004(a)(1), the Secretary is required, in consultation with representatives of other relevant federal agencies, to jointly review standards, implementation specifications, and certification criteria endorsed by the National Coordinator under section 3001(c) and subsequently determine whether to propose the adoption of such standards, implementation specifications, or certification criteria. Section 3004(a)(3) requires the Secretary to publish all such determinations in the 
                        <E T="04">Federal Register</E>
                        .
                    </P>
                    <P>
                        Section 3004(b)(3) of the PHSA, titled Subsequent Standards Activity, provides that the Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent with the schedule published by the HITAC. We consider this provision in the broader 
                        <PRTPAGE P="1202"/>
                        context of the HITECH Act and Cures Act to grant the Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITAC and endorsed by the National Coordinator, as well as other appropriate and necessary health IT standards, implementation specifications, and certification criteria.
                    </P>
                    <HD SOURCE="HD3">2. Health IT Certification Program(s)</HD>
                    <P>Section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a certification program or programs for the voluntary certification of health IT. Section 3001(c)(5)(A) specifies that the National Coordinator, in consultation with the Director of the National Institute of Standards and Technology (NIST), shall keep or recognize a program or programs for the voluntary certification of health IT that is in compliance with applicable certification criteria adopted under section 3004 of the PHSA. The certification program(s) must also include, as appropriate, testing of the technology in accordance with section 13201(b) of the HITECH Act. Section 13201(b) of the HITECH Act requires that, with respect to the development of standards and implementation specifications, the Director of NIST shall support the establishment of a conformance testing infrastructure, including the development of technical test beds. Section 13201(b) also indicates that the development of this conformance testing infrastructure may include a program to accredit independent, non-federal laboratories to perform testing.</P>
                    <P>
                        Section 4003(b) of the Cures Act added section 3001(c)(9)(B)(i) to the PHSA, which requires the National Coordinator “to convene appropriate public and private stakeholders” with the goal of developing or supporting a Trusted Exchange Framework and a Common Agreement (collectively, TEFCA
                        <SU>SM</SU>
                        ) for the purpose of ensuring full network-to-network exchange of health information. Section 3001(c)(9)(B) outlines provisions related to the establishment of a Trusted Exchange Framework for trust policies and practices and a Common Agreement for exchange between health information networks (HINs)—including provisions for the National Coordinator, in collaboration with the NIST, to provide technical assistance on implementation and pilot testing of TEFCA. Section 3001(c)(9)(C) requires the National Coordinator to publish TEFCA on its website and in the 
                        <E T="04">Federal Register</E>
                        .
                    </P>
                    <P>Section 4002(a) of the Cures Act amended section 3001(c)(5) of the PHSA by adding section 3001(c)(5)(D), which requires the Secretary, through notice and comment rulemaking, to require conditions of certification and maintenance of certification for the Program. Specifically, the health IT developers or entities with technology certified under the Program must, in order to maintain such certification status, adhere to certain conditions and maintenance of certification requirements concerning information blocking; assurances regarding appropriate exchange, access, and use of electronic health information; communications regarding health IT; APIs; real world testing; attestations regarding certain conditions and maintenance of certification requirements; and submission of reporting criteria under the EHR Reporting Program in accordance with section 3009A(b) of the PHSA.</P>
                    <HD SOURCE="HD2">B. Regulatory History</HD>
                    <P>The Secretary issued an interim final rule with request for comments on January 13, 2010, “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” (75 FR 2014), which adopted an initial set of standards, implementation specifications, and certification criteria. On March 10, 2010, the Secretary issued a proposed rule, “Proposed Establishment of Certification Programs for Health Information Technology” (75 FR 11328), that proposed both temporary and permanent certification programs for the purposes of testing and certifying health IT. A final rule establishing the temporary certification program was published on June 24, 2010, “Establishment of the Temporary Certification Program for Health Information Technology” (75 FR 36158), and a final rule establishing the permanent certification program was published on January 7, 2011, “Establishment of the Permanent Certification Program for Health Information Technology” (76 FR 1262).</P>
                    <P>We have engaged in multiple rulemakings to update standards, implementation specifications, certification criteria, and the certification program, a history of which can be found in the October 16, 2015 final rule “2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications” (80 FR 62602) (2015 Edition Final Rule). The history can be found at 80 FR 62606. A correction notice was published for the 2015 Edition Final Rule on December 11, 2015 (80 FR 76868), to correct preamble and regulatory text errors and clarify requirements of the Common Clinical Data Set (CCDS), the 2015 Edition privacy and security certification framework, and the mandatory disclosures for health IT developers.</P>
                    <P>The 2015 Edition Final Rule established a new edition of certification criteria (“2015 Edition health IT certification criteria” or “2015 Edition”) and a new 2015 Edition Base EHR definition. The 2015 Edition established the minimum capabilities and specified the related minimum standards and implementation specifications that certified electronic health record technology (CEHRT) would need to include to support the achievement of “meaningful use” by eligible clinicians, eligible hospitals, and critical access hospitals under the Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs) (now the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of MIPS) when the 2015 Edition is required for use under these and other programs referencing the CEHRT definition. The 2015 Edition Final Rule also adopted a proposal to change the Program's name to the “ONC Health IT Certification Program” from the ONC HIT Certification Program, modified the Program to make it more accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond the ambulatory and inpatient settings, and adopted new and revised Principles of Proper Conduct (PoPC) for ONC-Authorized Certification Bodies (ONC-ACBs).</P>
                    <P>
                        After issuing a proposed rule on March 2, 2016, “ONC Health IT Certification Program: Enhanced Oversight and Accountability” (81 FR 11056), we published a final rule by the same title (81 FR 72404) (EOA Final Rule) on October 19, 2016. The EOA Final Rule finalized modifications and new requirements under the Program, including provisions related to our role in the Program. The EOA Final Rule created a regulatory framework for our direct review of health IT certified under the Program, including, when necessary, requiring the correction of non-conformities found in health IT certified under the Program and suspending and terminating certifications issued to Complete EHRs and Health IT Modules. The EOA Final Rule also set forth processes for us to 
                        <PRTPAGE P="1203"/>
                        authorize and oversee accredited testing laboratories under the Program. In addition, it included provisions for expanded public availability of certified health IT surveillance results.
                    </P>
                    <P>On March 4, 2019, the Secretary published a proposed rule titled, “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (84 FR 7424) (ONC Cures Act Proposed Rule). The ONC Cures Act Proposed Rule proposed to implement certain provisions of the Cures Act that would advance interoperability and support the access, exchange, and use of electronic health information. We also requested comment in the ONC Cures Act Proposed Rule (84 FR 7467) as to whether certain health IT developers should be required to participate in TEFCA as a means of providing assurances to their customers and ONC that they are not taking actions that constitute information blocking or any other action that may inhibit the appropriate exchange, access, and use of EHI, with the goal of developing or supporting TEFCA for the purpose of ensuring full network-to-network exchange of health information.</P>
                    <P>On May 1, 2020, a final rule was published titled, “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (85 FR 25642) (ONC Cures Act Final Rule). The ONC Cures Act Final Rule implemented certain provisions of the Cures Act, including Conditions and Maintenance of Certification requirements for health information technology (health IT) developers, the voluntary certification of health IT for use by pediatric health providers, and reasonable and necessary activities that do not constitute information blocking. The ONC Cures Act Final Rule also implemented certain parts of the Cures Act to support patients' access to their EHI, and the implementation of information blocking policies that support patient electronic access. Additionally, the ONC Cures Act Final Rule modified the 2015 Edition health IT certification criteria and Program in other ways to advance interoperability, enhance health IT certification, and reduce burden and costs, as well as improving patient and health care provider access to EHI and promoting competition. On November 4, 2020, the Secretary published an interim final rule with comment period titled, “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency” (85 FR 70064) (Cures Act Interim Final Rule). The Cures Act Interim Final Rule extended certain compliance dates and timeframes adopted in the ONC Cures Act Final Rule to offer the healthcare system additional flexibilities in furnishing services to combat the COVID-19 pandemic, including extending the applicability date for information blocking provisions to April 5, 2021.</P>
                    <P>
                        On January 19, 2022, we published a notice titled, “Notice of Publication of the Trusted Exchange Framework and Common Agreement” (87 FR 2800) (“TEFCA”). The notice fulfilled an obligation under section 3001(c)(9)(C) of the PHSA, which requires the National Coordinator for Health Information Technology to publish on the Office of the National Coordinator for Health Information Technology's public internet website, and in the 
                        <E T="04">Federal Register</E>
                        , the trusted exchange framework and common agreement developed under the PHSA.
                    </P>
                    <P>On April 18, 2023, the Secretary published a proposed rule titled, “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” (HTI-1) (88 FR 23746) (HTI-1 Proposed Rule). The HTI-1 Proposed Rule proposed to implement the Electronic Health Record (EHR) Reporting Program provision of the 21st Century Cures Act by establishing new Conditions and Maintenance of Certification requirements for health IT developers under the Program. The HTI-1 Proposed Rule also proposed several updates to certification criteria and implementation specifications recognized by the Program, including a revised certification criterion for decision support and revised certification criteria for “patient demographics and observations” and “electronic case reporting.” Additionally, the HTI-1 Proposed Rule proposed to establish a new baseline version of the United States Core Data for Interoperability (USCDI). The HTI-1 Proposed Rule also proposed enhancements to support information sharing under the information blocking regulations. The implementation of these provisions would advance interoperability, improve transparency, and support the access, exchange, and use of electronic health information. The HTI-1 Proposed Rule also proposed to update the Program in additional ways to advance interoperability, enhance health IT certification, and reduce burden and costs and is subject of this final rule.</P>
                    <HD SOURCE="HD2">C. General Comments on the HTI-1 Proposed Rule</HD>
                    <P>
                        <E T="03">Comments.</E>
                         Numerous commenters expressed support for the overall direction of the HTI-1 Proposed Rule and its policy goals, including improved interoperability, standardization, reporting requirements, and electronic health information exchange. Many commenters also stated that the updated standards and certification criteria in the HTI-1 Proposed Rule would enhance patient and clinical access and enable health care providers to better meet patients' needs. A few commenters commended us for the protections for patients' privacy provided by the standards in the HTI-1 Proposed Rule. A few commenters also expressed appreciation for ONC providing clarity on certification criteria for certified health IT. A number of commenters stated that they looked forward to working with ONC and cooperating with the public and private sectors on improving interoperability for EHI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support expressed by many commenters. This final rule maintains the direction of the HTI-1 Proposed Rule, and we also look forward to ongoing collaboration with public and private sector partners as we implement the provisions of this final rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters expressed concern that the timeline for compliance deadlines for the standards in the HTI-1 Proposed Rule was too aggressive and that it was unrealistic for the health IT community to meet the requirements. Several commenters recommended delaying the compliance deadlines until at least two years after the date of publication of the final rule or providing a temporary enforcement safe harbor for developers and providers who are in the process of implementing the required changes. One commenter suggested that the timeline for adoption might be too aggressive and lead to health IT developers producing Health IT Modules that meet certification standards without providing the intended substantive benefits for patients and providers. A few commenters suggested that ONC create a standardized framework and cycle for adopting and requiring new and revised standards for certification criteria. Commenters suggested that ONC give more consideration to the burden placed on the health IT community by the requirements of both ONC and CMS standards, and work with CMS and other HHS agencies to more closely align standards and compliance dates.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' concerns about the timelines for 
                        <PRTPAGE P="1204"/>
                        conformance to new standards and certification criteria for the Program. After consideration of comments, we have finalized the adoption of certain certification criteria and standards with a compliance date of January 1, 2026, instead of the proposed compliance date of January 1, 2025, and noted in the specific certification criteria or standards each specific adopted conformance date. We have finalized the adoption of § 170.315(a)(5); (b)(1), (2), and (9); (e)(1); (f)(5); and (g)(6), (9), and (10) with a compliance date of January 1, 2026. We believe that these updated compliance dates, which are approximately two years from when this final rule published in the 
                        <E T="04">Federal Register</E>
                        , for certain criteria will allow developers increased flexibility and alleviate burden by allowing additional time for developers to prioritize updates, while also ensuring timely implementation of the requirements for health care providers and patients. We note that the compliance date defines the date by which a health IT developer with a Health IT Module certified to any revised certification criterion, as defined in § 170.102, must update the Health IT Module and provide such update to their customers in order for the Health IT Module to maintain certification.
                    </P>
                    <P>In response to commenters' recommendations for a standardized framework and cycle for updates to certification criteria, we appreciate commenters' concerns about the long-term timeline for updates to ONC Certification Criteria for Health IT. We have finalized our proposed approach to discontinue the use of year themed editions for ONC Certification Criteria for Health IT and adopt an incremental approach to updates to ONC Certification Criteria for Health IT. We believe that an incremental approach to updates will allow for a more consistent and transparent update cycle. We plan to issue clear guidance and timelines for when updates would be required.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters stated that the HTI-1 Proposed Rule and ONC's rulemaking schedule is overly complex, including a broad range of proposed changes to regulations. Some commenters recommended simplifying the proposals in this rule or creating a process to introduce more simplified regulatory updates in the future.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the concerns expressed about the complexity and broad scope of the changes to standards and the Program in this rule. Upon consideration of all the comments we have received, we have made adjustments, such as an extended implementation timeline for most standards and certification criteria and modified requirements for Health IT Modules certified to § 170.315(b)(11), in this final rule to alleviate the potential burden on developers of certified health IT and health care providers.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters stated that the adoption of a singular set of standards for EHI could have harmful effects for Health IT Modules. A few commenters were concerned that the standards in the HTI-1 Proposed Rule would not allow for specific standards for specialized or small health care providers. A few commenters were concerned that the requirements in the HTI-1 Proposed Rule could make health care providers dependent on collaboration with health IT developers to meet their obligations and could increase EHR fees for physicians or create bottlenecks that prevent physicians from adopting new EHR technology. Some commenters recommended that ONC provide assistance and guidance for providers to understand new requirements, and consider patient accessibility, particularly the limitations of patient literacy regarding healthcare and health IT, for requirements for patients' records. A number of commenters were concerned that the HTI-1 Proposed Rule's requirements for interoperability and patient access would not adequately protect patients' private information. Several commenters also recommended that ONC require greater transparency from health IT developers to foster an accessible health IT marketplace for consumers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We believe the updated standards and certification criteria will improve health IT interoperability and functionality for providers and patients. We thank commenters for their comments regarding privacy concerns and recognize the importance of addressing the privacy and confidentiality of sensitive information. Recognizing this, the Program establishes the standards, implementation specifications, and functional requirements for certified health IT to manage and exchange data but does not control the collection or use of data. For more on patient requested restrictions on sharing of their health information, we refer readers to section III.C.10 on modifications to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1), which addresses patients' (and their authorized representatives') ability to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. We also appreciate commenters recommending that we require greater transparency from health IT developers to foster an accessible health IT marketplace for consumers. As stated in the HTI-1 Proposed Rule (88 FR 23831) and this final rule, data collected and reported under the Insights Condition will address information gaps in the health IT marketplace and provide insights on the use of certified health IT. We believe that consumers will benefit from the increased transparency that the reporting requirements of Insights Condition will provide.
                    </P>
                    <P>While we believe that the language that we use in this rule provides clarity on the effects of this rule, as we did with the HTI-1 Proposed Rule, we will develop, as appropriate, resources such as infographics, FAQs, and fact sheets and provide webinars among other forms of educational materials and outreach to explain the effects of this rule for developers, providers, and patients.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested that ONC adopt a definition of “health IT developer” to provide more clarity regarding what entities may be considered developers for certification criteria.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We decline to adopt a new definition for “health IT developer” in this rule. Adopting a new definition for “health IT developer” would be out of scope for this rule because we did not propose a definition of “health IT developer” in the HTI-1 Proposed Rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended ONC include non-patient facing facilities (
                        <E T="03">e.g.,</E>
                         radiology) in the certified health IT requirements. This commenter stated that by establishing specialty-specific or size-specific health IT requirements, the goal of promoting interoperability across the healthcare landscape may be better achieved.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for their feedback. Including non-patient facing facilities in the certified health IT requirements was out of the HTI-1 Proposed Rule's scope. As we did not propose such changes to health IT requirements in the HTI-1 Proposed Rule, these changes would also be out of scope for this rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters raised issues that are out of scope for this rule, including concerns specifically about CMS policies and requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We reiterate that comments regarding CMS program requirements are out of scope as we cannot change CMS policy. We refer to readers to CMS programs for further information.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters requested that ONC provide technical 
                        <PRTPAGE P="1205"/>
                        assistance for the implementation of the requirements of this rule.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. As we did with the HTI-1 Proposed Rule, we will develop, as appropriate, resources such as infographics, FAQs, and fact sheets and provide webinars among other forms of educational materials and outreach to explain the effects of this rule for interest parties.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters identified issues that were out of scope for our proposal, such as requesting potential changes to the Cures Act and other federal legislation, and developing state local public health infrastructure and regulations with state and local health agencies.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' interest in federal legislation, and state and local public health infrastructure and regulations. Because we did not propose changes related to these areas in the HTI-1 Proposed Rule, these comments are out of scope, and we decline to finalize the recommended changes in this rule. ONC does not have the authority to change federal legislation through rulemaking. ONC looks forward to communicating with state and local public health agencies for the implementation of this rule and the development of future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We also received numerous comments that were out of scope or that recommended that ONC adopt new requirements that we did not propose and are not addressed in this rulemaking.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. These comments are out of scope for the HTI-1 Proposed Rule in that we did not propose changes to the requirements the comments addressed, and we decline to finalize such changes.
                    </P>
                    <HD SOURCE="HD1">III. ONC Health IT Certification Program Updates</HD>
                    <HD SOURCE="HD2">A. “The ONC Certification Criteria for Health IT” and Discontinuing Year Themed “Editions,” Definition of Revised Certification Criterion, and Related Program Oversight</HD>
                    <HD SOURCE="HD3">1. Discontinuing Year Themed “Editions”</HD>
                    <P>In the HTI-1 Proposed Rule, we stated that we no longer believed it was helpful or necessary to maintain an “edition” naming convention or to adopt entirely new editions of certification criteria to encapsulate updates over time (88 FR 23750). Instead, we proposed that there should be a single set of certification criteria, which would be updated in an incremental fashion in closer alignment to standards development cycles and regular health IT development timelines. We proposed in the HTI-1 Proposed Rule to rename all certification criteria within the Program simply as “ONC Certification Criteria for Health IT” (88 FR 23759). We explained that maintaining a single set of “ONC Certification Criteria for Health IT” would create more stability for users of health IT and Program partners, such as CMS, as well as make it easier for developers of certified health IT to maintain their product certificates over time. Unchanged certification criteria would no longer be duplicated as separate criteria under multiple editions. Accordingly, we proposed to rename § 170.315 as the “ONC Certification Criteria for Health IT” and replace all references throughout 45 CFR part 170 to the “2015 Edition” with this new description (this would impact the wording, though not the substance or effect, of §§ 170.102, 170.405, 170.406, 170.523, 170.524, and 170.550, as shown in the revised regulation text).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters were supportive of ONC's proposed approach to discontinue the use of year-themed editions for ONC Certification Criteria for Health IT, stating that it would reduce confusion. Commenters generally indicated that the change from year themed editions to adopting the name “ONC Certification Criteria for Health IT” would be understood by health IT developers, patients, and health care providers. Commenters stated and agreed that the previous naming convention inaccurately implied the age and outdatedness of the certification criteria and contributed to confusion about which edition was required for Program adherence. A number of commenters agreed that the change to incremental updates of certification criteria would be more efficient and allow for more flexibility than the edition-based updates to certification criteria that ONC has previously adopted. One commenter stated that such an approach would be more appropriate given the rapid pace at which health IT evolves. Another commenter favored the use of clear, regular, step-by-step updates in small portions, rather than complete overhauls of certification criteria. The commenter also favored a predictable timeline for updates based on standards development cycles with reasonable development timelines.
                    </P>
                    <P>Alternatively, some commenters expressed concern that discontinuing year-themed editions and adopting incremental advancement for certification criteria would create too much burden for developers of certified health IT and health care providers around updating Health IT Modules. Commenters stated that adopting incremental updates to many criteria instead of edition-based updates to criteria could lead to too many and too frequent deadlines for developers and providers to comply with and a significant added burden in cost and time. Commenters raised concerns that incremental standards updates may divert developer resources away from implementing provider requests. A few developers recommended that ONC adopt a regular cycle for updates and compliance to certification criteria and provide adequate time between revisions to criteria that accommodate typical development timelines for Health IT Modules. Numerous commenters contended that the proposed approach to discontinue the use of year-themed editions for ONC health IT certification criteria in favor of using the title “ONC Certification Criteria for Health IT” would not add sufficient clarity to the Program or would actually make the Program more difficult to understand. Commenters stated that the incremental updates for certification criteria could make it difficult for developers and consumers to understand which iterations of revised and updated standards are the most recently adopted criteria that Health IT Modules need to be certified to. A few commenters stressed that ONC should provide specificity and education regarding the standards that are necessary to participate in federal interoperability programs. Some commenters recommended that ONC create a listing of information on certification criteria that health IT developers and consumers could reference to determine the most up-to-date standards for a certification criterion and Health IT Module certified to such criterion. A few commenters requested greater clarity on how much responsibility consumers as opposed to developers would bear for maintaining the certification for Health IT Modules with the adoption of incremental advancements. One commenter was concerned that developers might charge providers the costs for updates and recommended that ONC add a requirement for developers to inform health care providers of the meaning of a “provider product” and the consequences of declining updates to health IT for participation in other federal programs.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank all commenters for their thoughtful feedback. Upon consideration of all comments received on this proposal, we have finalized our approach as proposed. As noted in the 
                        <PRTPAGE P="1206"/>
                        HTI-1 Proposed Rule (FR 23759), we believe that there should be a single set of certification criteria, which would be updated in an incremental fashion in closer alignment to standards development cycles and regular health IT development timelines. To finalize this proposal, we renamed all certification criteria within the Program simply as “ONC Certification Criteria for Health IT.” We believe maintaining a single set of “ONC Certification Criteria for Health IT” will create more stability for users of health IT and Program partners, such as CMS, as well as make it easier for developers of certified health IT to maintain their product certificates over time. In addition, we believe that this approach will have the benefit of reducing administrative burden for health IT developers participating in the Program. Previously, duplicative references to separate certification criteria under multiple, year-themed editions created administrative burden for health IT developers by requiring developers to seek an updated certificate attributed to the “new” duplicated certification criterion even in circumstances when the certification criterion remained substantively unchanged. Under this approach, unchanged certification criteria would no longer be duplicated as separate criteria under multiple editions. Accordingly, we renamed § 170.315 as the “ONC Certification Criteria for Health IT” and replaced all references throughout 45 CFR part 170 to the “2015 Edition” with this new description (this impacted the wording, though not the substance or effect, of §§ 170.102, 170.405, 170.406, 170.523, 170.524, and 170.550, as shown in the revised regulation text).
                    </P>
                    <P>With respect to those commenters that expressed reservations, discontinuing the use of year-themed editions for ONC Certification Criteria for Health IT will not impose a significant burden on implementers. Our intent with this approach is to maintain a single set of certification criteria that have been updated to include the most recent versions of adopted standards, and to establish an incremental approach to health IT updates over time. In fact, this has been embedded within the Program's approach all along because of the way we revised only certain certification criteria within an edition change. Moreover, in the ONC Cures Act Final Rule, we stated our belief that this kind of approach should also include development timelines based on the updates required for each criterion and a transition period allowing for either the prior adopted standard or the new standard to be used for a reasonable period of time (before shifting to exclusive use of the new standard). We further noted our belief that this approach can help to reduce the burden on health IT developers and health care providers and could allow health IT developers to implement updates in the manner most appropriate for their product and customers (85 FR 25665). We have received significant positive feedback expressing that the incremental approach to updates is generally beneficial as a long-term approach. Specifically, feedback conveyed that a consistent, transparent, incremental update cycle that includes the following features would be preferred by some: (1) regular updates to recognize standards advancement and an allowance for voluntary standards advancement between updates, (2) incremental updates rather than “wholesale” product overhauls, (3) a predictable timeline for updates based on standards development cycles with reasonable development timelines, and (4) a reasonable development timeline for any new criterion based on specific development needs. We plan to issue clear guidance and timelines for when updates would be required. In consideration of the overall support from commenters, we have finalized our proposed approach to discontinue the use of year themed editions for ONC Certification Criteria for Health IT.</P>
                    <P>In response to commenters that indicated we did not provide adequate specificity or education in our HTI-1 Proposed Rule, we appreciate the commenters' concerns and agree with the need for educational materials and resources. We intend to make updates to ONC website materials, engage in public presentations and webinars, and revise the Certified Health IT Product List (CHPL) database to make clear which certification criteria, standards, and implementation specifications are valid under the Program at a given point in time. Between the ONC website and the CHPL updates, we are confident that interested parties will have the necessary information regarding both certification criteria and certified health IT products. We will also develop educational resources so that purchasers and users understand which Health IT Modules have met their obligations under the Program by updating their Health IT Modules to revised certification criteria.</P>
                    <P>In response to the commenter suggestion that ONC add a requirement for developers to inform health care providers of the meaning of a “provider product” and the consequences for declining updates to health IT regarding participation in federal reporting programs, we thank the commenter for their comment. However, we have not proposed any requirements related to the term, “provider product,” and decline to finalize any such requirements in this final rule. Although we are not at this time requiring developers to inform health care providers of the consequences of declining updates to health IT, we encourage developers to be transparent with customers about the benefits of updates and impacts of declining them. We understand there are costs associated with updating new technology and also with foregoing participation in a federal program that requires the use of certified health IT. Therefore, we encourage developers to ensure that their customers are fully informed about all impacts before making a decision on updates.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested further clarity on issues related to the impact of the proposed approach on public health entities. Commenters noted that an approach should include an “expiration date” or identify minimum standards to ensure public health and other entities receiving data from certified health IT do not maintain support for outdated standards. Commenters also stated that the proposed approach should recognize the cost and implementation burden for public health agencies associated with updating standards, and that all regulatory impact analyses, including for the current rule, should include estimated costs for public health agencies, laboratories, and their intermediaries. Further, commenters recommended more attention on public input procedures, including from public health, and asked ONC to ensure that regulations do not update standards without verifying that public health authorities can meet the updated standards. Finally, one commenter suggested that ONC reference the authority of state, local, and territorial public health agencies within the standards update process to ensure clarity for users.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. We have identified in several places within 45 CFR part 170 subpart B, and within several certification criteria in 45 CFR part 170 subpart C, “expiration dates” and dates after which a standard or certification criterion is no longer valid within the context of the Program. We believe these dates will ensure public health and other entities receiving data from certified health IT do not maintain support for outdated standards. We understand concerns about the broader 
                        <PRTPAGE P="1207"/>
                        overall downstream impact of this rulemaking on entities beyond developers of certified health IT, which are specifically regulated under authorities delegated to ONC. This rule's impact analysis measures the estimated costs for developers of certified health IT to meet new Program requirements, for example, to develop or modify the technical functionality of their certified health IT or adopt a new standard or standard version. These are the expected direct costs of the rule's final policies on developers of certified health IT. However, we recognize that developers of certified health IT are largely private businesses that operate in a competitive marketplace and that they may not bear all costs to meet these requirements. We include in the “Costs and Benefits” section of the Regulatory Impact Analysis the estimated impact on certified health IT end users. In this case, health care providers, such as hospitals and clinicians. We believe these estimates provide a general, but not necessarily comprehensive, understanding of the possible pass-through costs borne by users of certified health IT.
                    </P>
                    <P>We also plan to issue educational resources explaining, consistent with standards and timelines adopted in this rule, when updates would be required. In addition, we actively engage with public health agencies to ensure that the regulatory process for updating standards represents their input. Finally, we indicate the authority of state, local, and territorial laws and requirements where appropriate.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that they did not support the change to an “edition-less” format because the availability of the Standards Version Advancement Process (SVAP) allows health IT developers to upgrade to approved standards on a voluntary basis. The commenter urged ONC to consider the following steps to mitigate burden on health IT developers: provide a minimum implementation time of 24 months for any new or updated criteria, utilize the SVAP process over required updates where feasible, accept “evidence-based” attestations for the purposes of certification, and work with other HHS agencies on awareness around updates to certification criteria.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As noted above, we plan to issue educational resources explaining, consistent with standards and timelines adopted in this rule, when updates would be required. In the ONC Cures Act Final Rule, as part of the Real World Testing Condition of Certification, we finalized a “flexibility” within the associated Maintenance of Certification that we refer to as the SVAP (85 FR 25775). This flexibility permits health IT developers to voluntarily use newer versions of adopted standards in their certified Health IT Modules so long as certain conditions are met. These conditions are not limited to, but notably include, successful real world testing of the Health IT Module using the new version(s) subsequent to the inclusion of these newer standards and implementation specification versions in the Health IT Module's certification. We established the SVAP not only to meet the Cures Act's goals for interoperability, but also in response to the feedback ONC has received through prior rulemakings and engagements, which advocated for ONC to establish a predictable and timely approach within the Program to keep pace with the industry's standards development efforts (85 FR 25775). We continue to support the SVAP, but we also believe it is necessary to discontinue the use of year-themed editions for ONC Certification Criteria for Health IT and adopt incremental updates to the Program. While SVAP allows flexibility for the voluntary adoption of newer versions of standards, the incremental Program updates will ensure aligned minimum requirements within the health IT industry that advance interoperability.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that moving to an “edition-less” approach would require ONC-ACBs to provide increased oversight to ensure certified health IT meets the specific compliance dates provided in regulation. Another commenter stated that ONC should provide a minimum of six months for developers and ONC-ACBs to implement this change, such as removing references to the 2015 Edition from documentation related to the Program.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback; however, we disagree that moving to an “edition-less” approach will require ONC-ACBs to conduct more oversight than under the edition-based construct. We note that while an “edition-less” approach may require different levels of documentation of oversight than currently exist in the Program, this approach will also likely reduce documentation and oversight in other areas given that health IT developers will not update Health IT Modules to all certification criteria at once, which was the case under the edition-based approach.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         All comments received were supportive of revising the text from “time-limited certification and certification status for certain 2015 Edition certification criteria” in § 170.550(m) to “time-limited certification and certification status for certain ONC Certification Criteria for Health IT.” Commenters noted that our proposal for time-limited certification should require products be clearly labeled and advertised as time-limited and include a description of which aspects of the product/certification are time-limited. Additionally, commenters requested we make a filterable tag in the CHPL and/or provide a list of the time-limited products separately.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support expressed by many commenters, and we have finalized the removal of “2015 Edition” from § 170.550(m). We look forward to ongoing collaboration with public and private sector partners as we implement the provisions of this final rule.
                    </P>
                    <P>After consideration of these comments, we have finalized our proposed approach to discontinue year-themed editions. Specifically, we have renamed § 170.315 as the “ONC Certification Criteria for Health IT” and replaced references to the “2015 Edition” in §§ 170.102, 170.405, 170.406, 170.523, 170.524, and 170.550, with this description.</P>
                    <HD SOURCE="HD3">2. Definition of “Revised Certification Criterion”</HD>
                    <P>In the HTI-1 Proposed Rule, we described the use of terms meant to describe the status of certification criteria for use in the Program from the 2011 to 2014 Edition transition (88 FR 23760). We also referenced the definitions finalized in the 2015 Edition Final Rule for the following terms:</P>
                    <P>• “New” certification criteria are those that as a whole only include capabilities never referenced in previously adopted certification criteria editions and to which a Health IT Module presented for certification to the 2015 Edition could have never previously been certified.</P>
                    <P>• “Revised” certification criteria are those that include the capabilities referenced in a previously adopted edition of certification criteria as well as changed or additional new capabilities; and to which a Health IT Module presented for certification to the 2015 Edition could not have been previously certified to all of the included capabilities.</P>
                    <P>
                        • “Unchanged” certification criteria are those that include the same capabilities as compared to prior certification criteria of adopted editions; and to which a Health IT Module presented for certification to the 2015 Edition could have been previously certified to all the included capabilities (80 FR 62608).
                        <PRTPAGE P="1208"/>
                    </P>
                    <P>We proposed that these same terms as applied to the certification criteria would continue to be used by the Program in the absence of a year-named edition. However, for clarity, we proposed to define “revised certification criterion (or criteria)” in § 170.102 to mean a certification criterion that meets at least one of the following: (1) has added or changed the capabilities described in the existing criterion in 45 CFR 170 part C; (2) has an added or changed standard or implementation specification referenced in the existing criterion in 45 CFR part 170 subpart B; or (3) is specified through notice and comment rulemaking as an iterative or replacement version of an existing criterion in 45 CFR part 170 subpart C.</P>
                    <P>
                        We stated in the HTI-1 Proposed Rule that we would continue to use these terms when: communicating proposals for future criteria, such as revising a criterion that will maintain its place in the CFR or establishing a new criterion that is an iterative or replacement criterion in the Program; establishing scenarios for when gap certification is an option for developers of certified health IT; and setting expiration dates or applicable timelines related to standards and certification criteria. Through the development of educational resources, such as fact sheets 
                        <SU>24</SU>
                        <FTREF/>
                         and resource guides,
                        <SU>25</SU>
                        <FTREF/>
                         these designations will help users and the public understand to which versions of standards and certification criteria a Health IT Module may be certified when multiple versions of standards or certification criteria are available under the Program. In the HTI-1 Proposed Rule, we proposed applicability or implementation timelines for both our certification criteria and the standards adopted in 45 CFR part 170 by establishing the dates by which an existing version of a criterion or standard is no longer applicable and by establishing a date by which a new or revised certification criterion or standard version is adopted (88 FR 23760).
                    </P>
                    <FTNT>
                        <P>
                            <SU>24</SU>
                             See 2015 Edition Cures Update Fact Sheet: 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2022-03/Cures-Update-Fact-Sheet.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>25</SU>
                             See API Resource Guide: 
                            <E T="03">https://onc-healthit.github.io/api-resource-guide/.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Most commenters supported our proposed definition of “revised certification criterion (or criteria).”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. We believe the revised certification criterion (or criteria) definition provides clarity around our approach for setting applicability or implementation timelines for both our certification criteria and the standards adopted in 45 CFR part 170. We have finalized our definition for revised certification criterion (or criteria) as proposed.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters suggested better coordination with the Centers for Medicare &amp; Medicaid Services (CMS) to ensure that our definition is consistent and aligned with the Medicare Promoting Interoperability (PI) Program or MIPS Promoting Interoperability performance category.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment and will continue to coordinate and work with our federal partners, including CMS, on points of intersection for potential future rulemaking. We note that the CY 2024 Physician Fee Schedule Proposed Rule 
                        <SU>26</SU>
                        <FTREF/>
                         has a discussion related to this policy, and we invite readers to review the discussion at 88 FR 52547.
                    </P>
                    <FTNT>
                        <P>
                            <SU>26</SU>
                             “Medicare and Medicaid Programs; CY 2024 Payment Policies Under the Physician Fee Schedule and Other Changes to Part B Payment and Coverage Policies; Medicare Shared Savings Program Requirements; Medicare Advantage; Medicare and Medicaid Provider and Supplier Enrollment Policies; and Basic Health Program” (88 FR 52262).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter inquired how users of a certified Health IT Module that has been certified to multiple certification criteria that have been revised and included overlapping timeframes for standards updates will know if the Health IT Module is compliant.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         ONC has included in the Code of Federal Regulations (CFR) revisions to certification criteria, standards, and implementation specifications—and their associated timelines. To meet a certification requirement, a Health IT Module would need to be updated to the most recently adopted capabilities and standards indicated in the CFR within the timelines specified. For example, if a finalized revised certification criterion references a new standard this year that must be adopted by 2027, and we subsequently revised this certification criterion through rulemaking again in 2026 with a newer version of that standard to be adopted by 2028, then the Health IT Module would need to be updated to the new standard identified this year in the CFR by 2027 and subsequently be updated to the standard identified through rulemaking in 2026 by 2028.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter inquired how an update to an existing criterion will be identified on the CHPL.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         ONC will establish clear requirements and timelines for all revised criteria within the CHPL. To support effective communication of the updates, we will implement a practical approach to facilitate transparency using the CHPL.
                    </P>
                    <P>Table 1 below includes the revised certification criteria we have finalized in this rule.</P>
                    <GPOTABLE COLS="2" OPTS="L2,nj,p1,8/9,i1" CDEF="xs72,r100">
                        <TTITLE>Table 1—List of Finalized Health IT Certification Criteria</TTITLE>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="1"> </CHED>
                        </BOXHD>
                        <ROW EXPSTB="01" RUL="s">
                            <ENT I="21">
                                <E T="02">Revised Certification Criteria</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00">
                            <ENT I="01">§ 170.315(a)(5)</ENT>
                            <ENT>Clinical—Patient demographics and observations (currently Demographics).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(a)(9)</ENT>
                            <ENT>Clinical—Clinical decision support (CDS) at § 170.315(a)(9) (to be moved to the “Care Coordination” certification criteria as the “decision support intervention” criterion at § 170.315(b)(11)”).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(b)(1)</ENT>
                            <ENT>Care Coordination—Transitions of care.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(e)(1)</ENT>
                            <ENT>Patient Engagement—View, download, and transmit to 3rd party.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(f)(5)</ENT>
                            <ENT>Public Health—Transmission to public health agencies—electronic case reporting.</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">§ 170.315(g)(10)</ENT>
                            <ENT>Design and Performance—Standardized API for patient and population services.</ENT>
                        </ROW>
                        <ROW EXPSTB="01" RUL="s">
                            <ENT I="21">
                                <E T="02">Revised Certification Criteria (standards updates)</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00">
                            <ENT I="01">§ 170.315(a)(12)</ENT>
                            <ENT>Clinical—Family health history.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(b)(2)</ENT>
                            <ENT>Care Coordination—Clinical information reconciliation and incorporation.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(b)(6)</ENT>
                            <ENT>Care Coordination—Data export.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(b)(9)</ENT>
                            <ENT>Care Coordination—Care plan.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(c)(4)</ENT>
                            <ENT>Clinical Quality Measures—Clinical quality measures—filter.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(f)(1)</ENT>
                            <ENT>Public Health—Transmission to immunization registries.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(f)(3)</ENT>
                            <ENT>Public Health—Transmission to public health agencies—reportable laboratory tests and values/results.</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="1209"/>
                            <ENT I="01">§ 170.315(f)(4)</ENT>
                            <ENT>Public Health—Transmission to cancer registries.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(g)(3)</ENT>
                            <ENT>Design and Performance—Safety-enhanced design.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(g)(6)</ENT>
                            <ENT>Design and Performance—Consolidated CDA creation performance.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(g)(9)</ENT>
                            <ENT>Design and Performance—Application access—all data request.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>In the HTI-1 Proposed Rule, we included proposed modifications to our approach for setting applicability or implementation timelines for each certification criteria and the applicable standards adopted in 45 CFR part 170 (88 FR 23761). In this final rule, we have finalized that proposal to incorporate the applicable timelines and “expiration dates” for capabilities and standards updates within each individual criterion or standard.</P>
                    <P>We direct readers to section III.C.11 of this final rule for further discussion of the requirements for health IT developers voluntarily participating in the Program related to health IT certification updates.</P>
                    <HD SOURCE="HD3">3. Program Oversight Related to Discontinuation of Editions</HD>
                    <HD SOURCE="HD3">a. Records Retention</HD>
                    <P>
                        In the ONC Cures Act Final Rule, we revised the Principles of Proper Conduct for ONC-ACBs and ONC-ATLs by amending the records retention policies to include the “life of the edition” (85 FR 25710 through 25713). Specifically, we clarified that the records retention provisions in §§ 170.523 and 170.524 included the “life of the edition” as well as three years after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules. We explained that “[b]ecause the `life of the edition' begins with the codification of an edition of certification criteria in the CFR and ends on the effective date of the final rule that removes the applicable edition from the CFR, the start and end dates for the `life of the edition' are published in the 
                        <E T="04">Federal Register</E>
                         in the rulemaking actions that finalize them. The period of three years beyond the `life of the edition' begins on the effective date of the final rule that removes the applicable edition from the CFR, thus the three-year period after removal from the CFR continues through three full calendar years following that date” (85 FR 25710).
                    </P>
                    <P>In the HTI-1 Proposed Rule, we proposed to maintain a single set of “ONC Certification Criteria for Health IT” and not an edition, so we therefore proposed to revise § 170.523 and § 170.524 (88 FR 23762). We proposed that the period of three years begins on the effective date of the final rule that removes the applicable ONC certification criterion or criteria for health IT from the CFR, thus the three-year period after removal from the CFR continues through three full calendar years following that date (in addition to the calendar year in which it was removed). We also retained the “Complete EHR” language in these sections because beginning with the 2015 Edition, Complete EHR certifications could no longer be issued. However, since the 2014 Edition was not removed from the CFR until the ONC Cures Act Final Rule, which became effective on June 30, 2020, records would need to be retained (including Complete EHRs) until June 30, 2023.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A majority of commenters, including individuals, professional trade associations, and other interested parties expressed support for the ONC-ATLs retaining the records of Complete EHRs' and Health IT Modules' testing through a minimum of three years from the effective date of the removal of those certification criteria from the CFR. Commenters indicated such requirements were reasonable, particularly in relation to the retirement of the edition concept, and they indicated that these records could better facilitate surveillance and enforcement of certification criteria and transparency for customers. One commenter highlighted the importance of retaining those records for historical documentation regarding their health IT vendors' certification status. One commenter suggested ONC expand the three-year requirement to six years, to align with the HIPAA Privacy Rule's retention period.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the commenters' support for continuing our current three-year retention policy and our proposed modifications that the retention policy would be effective for three full calendar years beginning on the effective date of the final rule that removes the applicable ONC certification criterion or criteria for health IT from the CFR. We agree that maintaining those records for historical documentation is important and have finalized our policy as proposed. We do not believe that a six-year retention policy is needed at this time because it may result in more burden than is warranted. However, we will continue to monitor the effectiveness of our existing retention policy and consider changes as needed, including consulting with Federal partners that conduct federal program enforcement, such as the HHS OIG.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters suggested ONC establish an organized system of documentation management for each Health IT Module/developer to be shared on the CHPL to streamline the process and enhance efficiency; to adopt new indicators of current certification status each time a criterion certified as part of a Health IT Module is incrementally updated; and to create a special coding system that represents the most current year of certification for Health IT Modules to support oversight and compliance requirements health care providers may have with other programs such as the CMS Quality Payment Program.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters identifying options for enhancing how the Program documents certification status for Health IT Modules as we retire the year-themed edition approach. We note that the CHPL primarily serves as a comprehensive repository of certified health IT products and their corresponding certification details. While it provides information about certified health IT products, it does not specifically serve as a documentation management system for Modules/developers. The CHPL provides transparency and access to certification information, including the certification criteria used for certifying a Health IT Module, test results, and certified health IT product details. It serves as a valuable resource for users to verify the certification status and capabilities of Health IT products. Overall, we will take these comments, and related comments received, into consideration as we implement removal of year-themed editions in the Program.
                    </P>
                    <HD SOURCE="HD3">b. Records Retention—Complete EHR</HD>
                    <P>
                        In the HTI-1 Proposed Rule, we proposed to retain the “Complete EHR” language in §§ 170.523 and 170.524 even though, beginning with the 2015 Edition, Complete EHR certifications could no longer be issued. We did so because the records for 2014 Edition Complete EHR certifications still needed to be retained until the records retention timeframe expired on June 30, 2023. Though not specifically stated in the HTI-1 Proposed Rule, the removal of 
                        <PRTPAGE P="1210"/>
                        the “Complete EHR” language from all reference points in §§ 170.523 and 170.524 could have been reasonably anticipated once June 30, 2023, had passed. Therefore, since the date has now passed and because retaining “Complete EHR” in the regulation text may cause confusion for the public, we have removed all remaining references to the “Complete EHR” language in §§ 170.523 and 170.524.
                    </P>
                    <HD SOURCE="HD2">B. Standards and Implementation Specifications</HD>
                    <HD SOURCE="HD3">1. National Technology Transfer and Advancement Act</HD>
                    <P>
                        The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 
                        <E T="03">et seq.</E>
                        ) and the Office of Management and Budget (OMB) Circular A-119 
                        <SU>27</SU>
                        <FTREF/>
                         require the use of, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular A-119 provide exceptions to electing only standards developed or adopted by voluntary consensus bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. Agencies have the discretion to decline the use of existing voluntary consensus standards if it is determined that such standards are inconsistent with applicable law or otherwise impractical, and instead use a government-unique standard or other standard. In addition to the consideration of voluntary consensus standards, the OMB Circular A-119 recognizes the contributions of standardization activities that take place outside of the voluntary consensus standards process. Therefore, in instances where use of voluntary consensus standards would be inconsistent with applicable law or otherwise impracticable, other standards should be considered that meet the agency's regulatory, procurement, or program needs, deliver favorable technical and economic outcomes, and are widely utilized in the marketplace.
                    </P>
                    <FTNT>
                        <P>
                            <SU>27</SU>
                             
                            <E T="03">https://www.whitehouse.gov/wp-content/uploads/2020/07/revised_circular_a-119_as_of_1_22.pdf.</E>
                        </P>
                    </FTNT>
                    <P>In this final rule, we use voluntary consensus standards except for:</P>
                    <P>
                        • The standard adopted in § 170.213, the United States Core Data for Interoperability Version 3 (USCDI v3), is a hybrid of government policy (
                        <E T="03">i.e.,</E>
                         determining which data to include in the USCDI) and voluntary consensus standards (
                        <E T="03">i.e.,</E>
                         the vocabulary and code set standards attributed to USCDI data elements); and
                    </P>
                    <P>• The standard adopted in § 170.207(f)(3) for race and ethnicity.</P>
                    <P>We are not aware of any voluntary consensus standards that could serve as an alternative for the purposes we describe in further detail throughout this final rule including establishing a baseline set of data that can be exchanged across care settings for a wide range of uses. We refer readers to section III.C.1 of this preamble for a discussion of the USCDI.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested ONC look at the work of the FHIR accelerators as meeting the requirements of `voluntary consensus bodies' outlined in the OMB Circular A-119 for standards and frameworks that fall outside of the HL7 process. The commenter stated that as an example, CARIN has worked with FAST to develop a framework for how digital identity is federated across healthcare participants with the CARIN/HHS Healthcare Digital Identity Federation Proof of Concept report in which ONC participated. The commenter encouraged ONC to leverage the open-source work that has been done to advance digital identity federation in future rulemaking.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. We will consider leveraging the work that the commenter suggested in future rulemakings.
                    </P>
                    <HD SOURCE="HD3">2. Compliance With Adopted Standards and Implementation Specifications</HD>
                    <P>
                        In accordance with Office of the Federal Register regulations related to “incorporation by reference,” 1 CFR part 51, which we follow when we adopt proposed standards and implementation specifications in any subsequent final rule, the entire standard or implementation specification document is deemed published in the 
                        <E T="04">Federal Register</E>
                         when incorporated by reference therein with the approval of the Director of the Federal Register. Once published, compliance with the standard and implementation specification includes the entire document unless we specify otherwise. If an element of the IG is optional or permissive in any way, it will remain that way for testing and certification unless we specified otherwise in regulation. In such cases, the regulatory text would preempt the permissiveness of the IG.
                    </P>
                    <HD SOURCE="HD3">3. “Reasonably Available” to Interested Parties</HD>
                    <P>
                        The Office of the Federal Register has established requirements for materials (
                        <E T="03">e.g.,</E>
                         standards and implementation specifications) that agencies propose to incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5(b)). To comply with these requirements, in section V (“Incorporation by Reference”) of this preamble, we provide summaries of, and uniform resource locators (URLs) to, the standards and implementation specifications we have adopted and subsequently incorporate by reference in the Code of Federal Regulations. To note, we also provide relevant information about these standards and implementation specifications throughout the relevant sections of this final rule.
                    </P>
                    <HD SOURCE="HD2">C. New and Revised Standards and Certification Criteria</HD>
                    <HD SOURCE="HD3">1. The United States Core Data for Interoperability Version 3 (USCDI v3)</HD>
                    <P>
                        As discussed in the HTI-1 Proposed Rule, the USCDI is a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange 
                        <SU>28</SU>
                        <FTREF/>
                         (88 FR 23751). USCDI v1 established a baseline set of data that can be commonly exchanged across care settings for a wide range of uses and is a required part of certification criteria in the 2015 Edition Cures Update. For the overall structure and organization of USCDI, including data classes and data elements in USCDI v1, please see the discussion in the ONC Cures Act Final Rule (85 FR 25669-25670), as well as 
                        <E T="03">www.healthIT.gov/uscdi.</E>
                    </P>
                    <FTNT>
                        <P>
                            <SU>28</SU>
                             
                            <E T="03">https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi.</E>
                        </P>
                    </FTNT>
                    <P>
                        We stated in the ONC Cures Act Final Rule that we intended to utilize a predictable, transparent, and collaborative process to expand USCDI, including providing the public with the opportunity to comment on USCDI's expansion (85 FR 25670). We also noted that developers of certified health IT would be able to use the Standards Version Advancement Process (SVAP) to voluntarily implement and use a newer, National Coordinator-approved version of USCDI without waiting for ONC to propose and adopt via rulemaking an updated version of the USCDI (85 FR 25669). We, therefore, established a process for expanding USCDI based on public input and submissions of new data elements and classes.
                        <SU>29</SU>
                        <FTREF/>
                         To enable these submissions, we created the ONC New Data Element and Class (ONDEC) submission system, which provides the public with the opportunity to submit new data 
                        <PRTPAGE P="1211"/>
                        elements for consideration for inclusion in future versions of USCDI.
                        <SU>30</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>29</SU>
                             
                            <E T="03">https://www.healthit.gov/buzz-blog/interoperability/uscdi-onc-new-data-element-and-class-submission-system-now-available.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>30</SU>
                             
                            <E T="03">https://www.healthit.gov/isa/ONDEC.</E>
                        </P>
                    </FTNT>
                    <P>In the HTI-1 Proposed Rule, we proposed to update the USCDI standard in § 170.213 by adopting the newly released USCDI v3 and establishing a January 1, 2025, expiration date for USCDI v1 (July 2020 Errata) for purposes of the Program. We proposed to add USCDI v3 in § 170.213(b) and incorporate it by reference in § 170.299. Specifically, we proposed in the HTI-1 Proposed Rule to adopt USCDI v3 (October 2022 Errata). We also proposed to codify the existing reference to USCDI v1 (July 2020 Errata) in § 170.213(a). Lastly, we proposed that as of January 1, 2025, any developers seeking certification for their Health IT Modules to criteria that reference the standards in § 170.213 would need to be capable of exchanging the data elements that comprise USCDI v3.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a large number of comments expressing overall support for our proposals to adopt USCDI v3 in § 170.213(b) and for USCDI v1 to expire on January 1, 2025. Many commenters specifically supported the inclusion of SDOH data elements in USCDI v3 and noted that more accurate and complete patient characteristics will help address health disparities. Several commenters in support of our proposals specifically agreed with the proposed deadline. Commenters supporting our proposal also noted that it would reduce burden, advance interoperability, support quality measurement initiatives, and support providers' ability to acquire and share the information needed to provide the best care for their patients.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the support of our proposals and for recognizing potential benefits such as reduced burden, increased interoperability, more complete data, and the ability to support quality measurement initiatives and better address health disparities.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received numerous comments that expressed concern about the proposed deadline and advocated for an extension. These comments generally expressed concern about the burden on developers posed by the proposed deadline, stating that more time would be needed to successfully adopt USCDI v3, including development, implementation, and testing, and stressed that it would be a large undertaking for developers as well as for health care providers. Some commenters recommended moving the deadline to the end of the calendar year which is no shorter than 24 months from the publication of this final rule. Some commenters suggested extending the compliance deadline by six months, and others suggested compliance dates of December 31, 2025, or January 1, 2026. Several commenters mentioned the need for ONC to coordinate with CMS on timelines, and one mentioned the need to allow providers a “flex” year after the certification deadline during which to upgrade. Some comments suggested aligning compliance deadlines with the availability of scalable FHIR-based API standards, which they stated could help support successful implementation of USCDI v3, while others suggested waiting to adopt USCDI v3 until after Release 4 of the C-CDA Companion Guide is finalized. Some commenters stated that USCDI v3 should not be required until all of the standards supporting USCDI v3 are officially published.
                    </P>
                    <P>Additionally, a number of commenters requested clarification from ONC related to the proposed adoption of USCDI v3. This included clarification on future updates to USCDI; how USCDI works with CMS rules and programs; the applicability of USCDI v2 once USCDI v3 is adopted; the distinction between USCDI, USCDI+ and US Core; the lack of vocabulary standards for some USCDI v3 data elements; and the expectations regarding data sharing.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for expressing a desire for an extension on proposed deadlines. USCDI v3 includes all data elements in USCDI v2, as well as additional data elements. In response to commenters' feedback, we have extended the deadline for the expiration of USCDI v1 in § 170.213 to January 1, 2026. We believe the extended time, combined with the fact that USCDI v3 has been publicly available since July 2022, will make it feasible for all interested parties to meet the revised deadline. We note that USCDI v3 has been available for use in the Program using the FHIR US Core 6.1.0 and C-CDA Companion Guide R4.1 through SVAP effective September 11, 2023.
                        <SU>31</SU>
                        <FTREF/>
                         In response to comments suggesting that USCDI v3 lacks vocabulary standards, in the USCDI v3 standard ONC has identified applicable vocabulary standards for those USCDI data elements where a coded value is expected, a standard code set is currently in use, and where the submitters and commenters have provided evidence of current use. Further terminology bindings are defined in the C-CDA Companion Guide and HL7 US Core Implementation Guide.
                    </P>
                    <FTNT>
                        <P>
                            <SU>31</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/2023-07/2023_SVAP_Fact_Sheet.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>In response to the comment requesting that ONC explain the distinction between USCDI, USCDI+, and US Core, we note that the USCDI+ program was not referenced in the HTI-1 Proposed Rule. USCDI+ supports the identification and establishment of domain or program-specific datasets that will operate as extensions to USCDI and uses similar processes as the USCDI, such as seeking input from the Health IT Advisory Committee and other interested partners to stimulate public engagement and help shape USCDI+ datasets.</P>
                    <P>As we have described previously, the USCDI is a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange. In order for the USCDI to be implemented with specific exchange modalities or functionalities, additional specifications are required to provide guidance on how the USCDI should be implemented in the context of that exchange method. The US Core and C-CDA implementation guides are aligned to specific versions of USCDI and provide the implementation specification and expectations for each particular version of USCDI. In this case, we have finalized USCDI v3 and the applicable FHIR US Core Implementation Guide (FHIR US Core 6.1.0) and C-CDA Companion Guide (C-CDA Companion Guide R4.1), both of which provide guidance on how to implement the updates from USCDI v1 to USCDI v3.</P>
                    <P>
                        We recognize that we stated in the HTI-1 Proposed Rule that we would consider adopting the most up-to-date versions of the FHIR US Core and C-CDA Companion Guide specifications that align with the updates to USCDI v3 (FHIR US Core 6.0.0 and C-CDA Companion Guide R4). However, after the publishing of FHIR US Core 6.0.0 and C-CDA Companion Guide R4, HL7 found errors with how the guides implemented data elements in USCDI v3 and had to make updates to those specifications to align with USCDI v3 and ensure that USCDI v3 can be implemented in Health IT Modules. Adopting FHIR US Core 6.1.0 and C-CDA Companion Guide R4.1 is necessary for developers of certified health IT to have appropriate implementation guidance to meet the criteria adopted in this final rule that reference USCDI v3. Based on public comments on this and prior rulemakings, we believe that the health IT industry, healthcare standards developers, and health care providers expect and support ONC making such 
                        <PRTPAGE P="1212"/>
                        determinations so that the adopted version of standards are the most up-to-date available and are feasible for real-world implementation (see, for example, 85 FR 25677 and 25708).
                    </P>
                    <P>In response to comments regarding how CMS or other federal programs incorporate USCDI into rules and programs, we note that ONC receives submissions and comments from federal partners, including CMS, on USCDI content and will continue to work towards alignment where appropriate with these partners.</P>
                    <P>
                        In response to comments on future updates to USCDI, we clarify that USCDI generally expands annually to keep pace with clinical, technology, and policy changes.
                        <SU>32</SU>
                        <FTREF/>
                         ONC follows a predictable, transparent, and collaborative process for updating USCDI that allows interested parties to submit new data elements and classes for future versions of USCDI through the ONDEC submission system. Regarding applicability, USCDI v2 will not be available for new and updating certifications via SVAP after December 31, 2023. We erroneously stated in the HTI-1 Proposed Rule that USCDI v2 would remain available via SVAP until December 31, 2024 (88 FR 23764); however, our intention was that USCDI v2 would remain available via SVAP until it sunsets. USCDI v2 sunsets on December 31, 2023 and will no longer be available via SVAP after that date.
                        <SU>33</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>32</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2023-07/Standards_Bulletin_2023-2.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>33</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/standards-version-advancement-process-svap</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         We received numerous comments expressing concerns about privacy and the implementation of USCDI v3. These commenters generally noted that USCDI v3 includes data elements that may contain sensitive health information, including mental health, substance use, and reproductive health information, the disclosure of which could increase the risk of harassment or harm toward providers and patients. Several of these commenters noted the need for ONC to create education materials around the fact that USCDI v3 does not require sharing of sensitive information. Some commenters recommended that ONC remove data elements that provide personally identifiable information that does not support the provision of care. Several comments encouraged ONC to consider requiring granular data segmentation policies concurrently with adopting USCDI v3. Commenters also requested that ONC consider removing any personally identifiable data elements in USCDI that do not provide value in order to avoid re-identification, or alternatively to revise policies that require automatic inclusion of all data elements in the USCDI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback regarding the importance of addressing the privacy and confidentiality of sensitive information. The adoption of USCDI v3 sets a new baseline for the capability of Health IT Modules certified to particular certification criteria to capture and exchange data but does not dictate when and how either of those two actions occur. We have not adopted new or additional privacy standards related to controlling sensitive data that may be represented in USCDI data elements. However, our existing criteria in § 170.315(b)(7) and (b)(8) include support for privacy and security labels in health information exchange workflows and these criteria reference the HL7® Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 adopted in § 170.205(o)(1) and incorporated by reference in § 170.299. In addition, we have adopted a new requirement as part of the certification criterion in § 170.315(e)(1) in support of the HIPAA Privacy Rule's individuals' “right to request a restriction” as discussed in section III.C.10. For more on patient requested restrictions on sharing of their health information, we refer readers to section III.C.10 for discussion on modifications to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1), stating that patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. The HIPAA Privacy Rule provides federal protections for PHI held by covered entities and gives individuals an array of rights with respect to that information.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received multiple comments expressing concern about provider burden, including administrative, cognitive, and documentation burden associated with USCDI data elements. Some commenters also expressed concerns about the cost burden of implementing USCDI v3, noting that it could require numerous downstream standards updates, migration costs, costs to standardize and use unconstrained data, and costs related to software, IT infrastructure, workforce recruiting and training, and ongoing operational costs. Several commenters were particularly concerned about the potential costs to public health organizations and to small and rural providers, which may have limited budgets or resources to devote to the implementation of EHR systems capable of collecting and sharing data according to the USCDI v3 standard. Several commenters suggested that ONC provide resources and support to providers to help reduce provider burden. One commenter proposed a test or pilot to ensure that burdens are not shifted to providers when USCDI v3 is implemented. Another commenter proposed that ONC consider regulations to prevent developers of certified health IT from increasing fees due to the update to USCDI v3.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the feedback regarding implementation burden and the adoption of USCDI v3. As we have noted, the adoption of USCDI v3 sets a new baseline for the 
                        <E T="03">capability</E>
                         of Health IT Modules certified to particular certification criteria to capture and exchange data. USCDI v3 does not dictate when and how either of those two actions occur, including with what frequency health care providers document information that could be captured as part of the data elements within USCDI v3. We also note that we have established a predictable, transparent, and collaborative expansion process for USCDI based on public evaluation of previous versions and submissions by the health IT community. Each of the data elements in USCDI v3 has been evaluated for overall value, maturity, and ease of implementation. In addition, the data elements (as applicable) are represented by health IT standard terminologies, technical specifications, or implementation guides, and are used extensively in production electronic systems. We intend to provide implementation resources such as implementation guide validators for both HL7 C-CDA and FHIR corresponding implementation guides to USCDI v3. However, we decline to conduct a test pilot or create additional regulations focused on burden and USCDI v3 at this time.
                    </P>
                    <P>We appreciate the comments related to implementation burden for rural and small providers and understand concerns about the overall downstream impact of the HTI-1 Proposed Rule on entities beyond developers of certified health IT to which ONC authorities apply. As part of our Regulatory Impact Analysis in section VII, we have identified that developers of certified health IT are largely private businesses who operate in a competitive marketplace, and they may not bear all costs to meet regulatory requirements.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concerns about data quality when USCDI v3 is implemented and suggested that ONC work with the 
                        <PRTPAGE P="1213"/>
                        industry on developing standards. Several commenters expressed concerns about the lack of use cases and standards related to USCDI v3 and suggested that ONC develop those.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We work directly with HL7 to finalize HL7® FHIR® US Core and C-CDA Companion Guide specifications for each published version of USCDI, including USCDI v3. These specifications include terminology bindings to value sets drawn from standard code sets, where appropriate. To further support implementation of USCDI v3, we will update the C-CDA validator 
                        <SU>34</SU>
                        <FTREF/>
                         and Inferno 
                        <SU>35</SU>
                        <FTREF/>
                         test tools to align with USCDI v3 and validate the quality of the data. We will continue to identify opportunities to work with industry to improve data quality. For example, we recently awarded a Leading Edge Acceleration Project (LEAP) award to explore enabling easy access to high-quality, standardized healthcare data, with a focus on USCDI in FHIR and open-source platforms.
                        <SU>36</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>34</SU>
                             
                            <E T="03">https://site.healthit.gov/sandbox-ccda/ccda-validator</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>35</SU>
                             
                            <E T="03">https://inferno.healthit.gov/</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>36</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2023-04/LEAP%20FY2023%20SEN_508.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concern that not all data elements in USCDI v3 are applicable to all users and urged that ONC allow EHRs flexibility in adopting USCDI v3. These commenters generally urged ONC to allow EHRs to add only the data elements needed by their users. Commenters also urged ONC to explore a modular approach for USCDI that would group data elements to support specific use cases, noting that this would help reduce burden and costs while improving care.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the input suggesting that ONC allow flexibility in supporting USCDI v3 data classes and data elements for purposes of the Program. We decline to allow developers to be selective in which USCDI v3 data classes and data elements they support for purposes of the Program. The USCDI standard is intended to provide a common set of data classes and data elements in support of nationwide health information exchange, therefore, partial adoption of the USCDI standard would impact the effectiveness of the standard and impede interoperability. Additionally, we recognize that not all USCDI v3 data elements originate in an EHR, however Health IT Modules certified to particular certification criteria must be able to capture and exchange the values when available.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested that ONC establish a framework for certification of specialty EHRs and non-EHRs to help promote USCDI uptake across the care continuum.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for their suggestion that ONC establish a framework for certification to support specialty EHRs and non-EHRs to promote USCDI uptake across the care continuum. At this time, we decline to provide selective certification frameworks for purposes of the Program. The USCDI standard is intended to provide a common set of data classes and data elements in support of nationwide health information exchange.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed a preference for USCDI v4 over USCDI v3, noting that it will help the healthcare marketplace and encourage competition. One comment encouraged ONC to finalize USCDI v4 in 2023 and require support by the end of 2024.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the comments in support of USCDI v4. However, we did not propose, and therefore decline to adopt, USCDI v4 in the USCDI standards in § 170.213 at this time. We have adopted USCDI v3 in § 170.213(b) as proposed. Additionally, we note that implementation guides are not yet released to support USCDI v4.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters generally encouraged ONC to work with CMS on timelines and on alignment with program requirements, including aligning future USCDI updates with CMS programs.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the comments regarding working with CMS and assure commenters that we work closely with CMS across multiple programs and initiatives on aligning program requirements and deadlines. We will continue to do so in the future. Those CMS programs include, but are not limited to, the Quality Payment Program, Inpatient Quality Reporting Program, and Medicare Promoting Interoperability Program, as well as regulatory proposals such as the Interoperability and Prior Authorization Proposed Rule (87 FR 76238).
                        <SU>37</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>37</SU>
                             “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.” (87 FR 76238). 
                            <E T="03">See https://www.federalregister.gov/documents/2022/12/13/2022-26479/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-advancing-interoperability</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters encouraged ONC to maintain awareness of state agency data exchange requirements and to work to alleviate discrepancies, noting that the variances in USCDI versioning pose challenges industry-wide if not aligned with state and federal regulations.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the comments regarding state agency data exchange requirements and assure commenters that we monitor and are aware of state and federal regulations impacting adoption of USCDI v3.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         There were a number of comments requesting technical support, education, and other resources or actions from ONC related to adopting and implementing USCDI v3. These included addressing semantic differences across health systems, developing mappings and value sets for data elements, improving the specificity and testing requirements for USCDI, expediting the availability of high-quality testing tools, developing and publicizing an analysis of which USCDI elements are interoperable, and aligning data standardization efforts across programs.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We acknowledge the comments requesting resources and technical support from ONC related to adoption of USCDI v3. We maintain a variety of resources and technical support related to USCDI, including numerous resources related to the Program. Resources include Certification Companion Guides (CCGs) and Test Procedures related to specific certification criterion to assist developers that are seeking to certify to the criteria.
                        <SU>38</SU>
                        <FTREF/>
                         Any considerations for implementing USCDI in compliance with these criteria are, additionally, outlined in these resources. In addition, there is a USCDI CCG that includes clarifications for specific data classes and elements as they relate to terminology standards and/or implementation guides. The Program offers testing and conformance methods for verification that a product meets criteria requirements. Other technical documentation may be found on ONC's website: 
                        <E T="03">https://www.healthit.gov/uscdi</E>
                        .
                    </P>
                    <FTNT>
                        <P>
                            <SU>38</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/certification-ehrs/certification-health-it</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         There were also a number of commenters that made suggestions for future versions of USCDI. Commenters suggested improving the USCDI interface and allowing comment on proposed value sets. Various commenters suggested adding specific 
                        <PRTPAGE P="1214"/>
                        data elements in future versions of USCDI, including the following:
                    </P>
                    <FP SOURCE="FP-1">• marital status</FP>
                    <FP SOURCE="FP-1">• education</FP>
                    <FP SOURCE="FP-1">• water insecurity</FP>
                    <FP SOURCE="FP-1">• value-based care</FP>
                    <FP SOURCE="FP-1">• prescription drug insurance information</FP>
                    <FP SOURCE="FP-1">• advance directive documentation</FP>
                    <FP SOURCE="FP-1">• clinical orders</FP>
                    <FP SOURCE="FP-1">• care experience preference</FP>
                    <FP SOURCE="FP-1">• newborn delivery information</FP>
                    <FP SOURCE="FP-1">• vaccine administration date</FP>
                    <FP SOURCE="FP-1">• vaccination event record type</FP>
                    <FP SOURCE="FP-1">• medical record number</FP>
                    <FP SOURCE="FP-1">• mother's maiden name</FP>
                    <FP SOURCE="FP-1">• multiple birth indicator</FP>
                    <FP SOURCE="FP-1">• birth order</FP>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the feedback and suggestions regarding future versions of USCDI. The USCDI v3 is a published standard at 
                        <E T="03">https://www.healthit.gov/isa/sites/isa/files/2022-10/USCDI-Version-3-October-2022-Errata-Final.pdf</E>
                         and thus it is not possible to add new data elements to USCDI v3 through the rulemaking process or other means at this time. We direct commenters to the USCDI website, available at 
                        <E T="03">https://www.healthit.gov/uscdi,</E>
                         where the public is invited to enter comments on leveled data elements or submit new data elements for consideration in future versions of USCDI.
                    </P>
                    <HD SOURCE="HD3">a. Certification Criteria That Reference USCDI</HD>
                    <P>As discussed in the HTI-1 Proposed Rule, the USCDI standard is currently cross-referenced, via cross-reference to § 170.213, in certain certification criteria (88 FR 23763). The criteria cross-referencing to USCDI via cross-reference to § 170.213 are as follows:</P>
                    <P>
                        • “Care coordination—Transitions of care—Create” (§ 170.315(b)(1)(iii)(A)(
                        <E T="03">1</E>
                        ));
                    </P>
                    <P>
                        • “Care coordination—Clinical information reconciliation and incorporation—Reconciliation” (§ 170.315(b)(2)(iii)(D)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">3</E>
                        ));
                    </P>
                    <P>
                        • “Patient engagement—View, download, and transmit to 3rd party—View” (§ 170.315(e)(1)(i)(A)(
                        <E T="03">1</E>
                        ));
                    </P>
                    <P>• “Design and performance—Consolidated CDA creation performance” (§ 170.315(g)(6)(i)(A));</P>
                    <P>
                        • “Design and performance—Application access—all data request—Functional requirements” (§ 170.315(g)(9)(i)(A)(
                        <E T="03">1</E>
                        )); and
                    </P>
                    <P>• “Design and performance—Standardized API for patient and population services—Data response” (§ 170.315(g)(10)(i)(A) and (B)).</P>
                    <P>We noted in the HTI-1 Proposed Rule that § 170.315(f)(5) also currently references § 170.213; however, we proposed to rely on specific IGs for that criterion, rather than reference § 170.213 (88 FR 23763). We proposed that through December 31, 2024, a Health IT Module certified to the criteria above that cross-reference § 170.213 may be certified by complying with (1) USCDI v1; (2) USCDI v2 under SVAP; and (3) USCDI v3 (88 FR 23763). We proposed to allow only USCDI v3 after this date for the criteria that cross-reference § 170.213.</P>
                    <P>We noted in the HTI-1 Proposed Rule that a developer of certified health IT will not be required to provide technology updates for certified criteria or standards to a user who declined such updates; however, if such an update is not provided, that version of the Health IT Module will no longer be considered certified under the Program (88 FR 23764).</P>
                    <P>In the HTI-1 Proposed Rule, we proposed in the preamble to add introductory text to § 170.213 noting that the Secretary adopts the following standards as the standards available for representing EHI (88 FR 23764), and we proposed in the regulatory text to add introductory text to § 170.213 stating the Secretary adopts the following versions of the USCDI standard (88 FR 23907). This discrepancy was inadvertent, and we clarify that we intended to propose introductory text to § 170.213 stating the Secretary adopts the following versions of the USCDI standard. We also proposed to include the date the adoption of the standard in § 170.213(a) expires. Consistent with our proposals in sections III.A and III.C.11, we proposed this expiration date to be January 1, 2025. Health IT developers with Health IT Modules certified to certification criteria that reference § 170.213 would have to update such certified health IT to USCDI v3 and provide it to customers by December 31, 2024. Further, we proposed that Health IT Modules certified to the above-listed certification criteria would need to update their Health IT Modules to accommodate USCDI v3 data elements using the FHIR US Core Implementation Guide Version 5.0.1 in § 170.215(b)(1)(ii) and the HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 in § 170.205(a)(6). We noted in the HTI-1 Proposed Rule that if the FHIR US Core Implementation Guide and the HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide are updated before the date of publication of this final rule, it would be our intent to consider adopting the updated versions that support USCDI v3.</P>
                    <P>We refer to the term “expires” in standards throughout this final rule, and it means that the standard is unavailable for use in the Program, or any other programs that may cite the standard, as of the expiration date.</P>
                    <P>
                        Additionally, because we finalized in the ONC Cures Act Final Rule that the Common Clinical Data Set (CCDS) would no longer be applicable for certified Health IT Modules 24 months after the publication date of the ONC Cures Act Final Rule (85 FR 25671), and then extended that date to December 31, 2022, in the interim final rule titled “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency” (85 FR 70073), we proposed to remove references to CCDS in the following sections of 45 CFR 170.315: § 170.315(b)(1)(iii)(A)(
                        <E T="03">2</E>
                        ); (e)(1)(i)(A)(
                        <E T="03">2</E>
                        ); (g)(6)(i)(B); and (g)(9)(i)(A)(
                        <E T="03">2</E>
                        ). In each of those sections, we proposed to instead include a reference to USCDI. Because § 170.315(b)(6)(ii)(A), which also references CCDS, is still available for the period before December 31, 2023, we did not propose to remove the reference to CCDS in that section.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters expressed support for ONC's proposals regarding certification criteria that reference USCDI. Commenters stated this would support health equity by design, help capture more accurate and complete patient data, and help address health disparities.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for support of our proposals and for recognizing the potential benefits. We note that the implementation guides we proposed in the HTI-1 Proposed Rule aligned with USCDI v2, and since the publication of the HTI-1 Proposed Rule, HL7 released updated FHIR US Core and C-CDA Companion Guides that align with the updates to USCDI v3. However, after the publishing of US Core 6.0.0 and C-CDA Companion Guide 4.0, HL7 found errors with how the guides implemented data elements in USCDI v3 and had to make updates to those specifications to align with USCDI v3 and to ensure that USCDI v3 can be implemented in Health IT Modules. Given the adoption of USCDI v3, we have finalized the FHIR US Core 6.1.0 and C-CDA Companion Guide R4.1, which are the most recent versions that align with USCDI v3. FHIR US Core 6.1.0 and C-CDA Companion Guide R4.1 have not added any substantial functionality or requirements. We do not believe adoption of FHIR US Core 6.1.0 and C-CDA Companion Guide R4.1 would contribute to a greater 
                        <PRTPAGE P="1215"/>
                        implementation burden, and FHIR US Core 6.1.0 and C-CDA Companion Guide R4.1 are the only versions of their respective implementation guides that fully align with and support the complete USCDI v3.
                    </P>
                    <P>
                        As discussed earlier in this section, we recognize that we stated in the HTI-1 Proposed Rule that we would consider adopting the most up-to-date versions of the FHIR US Core and C-CDA Companion Guide specifications that align with USCDI v3 
                        <E T="03">FHIR US Core 6.0</E>
                        <E T="7601">1</E>
                        <E T="03">.0 and C-CDA Companion Guide R4)</E>
                        <E T="7601">.1</E>
                        . However, after the publishing of 
                        <E T="03">FHIR</E>
                         US Core 6.0.0 and C-CDA Companion Guide R4, HL7 found errors with how the guides implemented data elements in USCDI v3 and had to make updates to those specifications to align with USCDI v3 and ensure that USCDI v3 can be implemented in Health IT Modules. Adopting FHIR US Core 6.1.0 and C-CDA Companion Guide R4.1 is necessary for developers of certified health IT to have appropriate implementation guidance to meet the criteria adopted in this final rule that reference USCDI v3. Based on public comments on this and prior rulemakings, we believe that the health IT industry, healthcare standards developers, and health care providers expect and support ONC making such determinations so that the adopted version of standards are the most up-to-date available and are feasible for real-world implementation (see, for example, 85 FR 25677 and 25708).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters suggested ONC should establish a more formal schedule for adopting future versions of USCDI into the Program, in addition to requests for clarification on the availability of USCDI v2 under SVAP. Commenters also recommended updating SVAP to allow at least two new versions of the same standard (
                        <E T="03">e.g.,</E>
                         USCDI v2 and USCDI v3) to be available under SVAP at a time.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for the suggestion. Generally, ONC updates USCDI on an annual basis, usually over the summer after an extensive public comment period. We decline to adopt a more formalized schedule; however, we promote widely the availability of draft versions of USCDI and engage heavily with interested parties, including the HITAC on new versions. As finalized in this rule, developers of certified health IT are able to certify Health IT Modules to certification criteria that reference USCDI v1 until it expires on January 1, 2026. Beginning on January 1, 2026, only USCDI v3 will be available in § 170.213 as the USCDI standard for use by developers of certified health IT. Under SVAP, developers of certified health IT had the opportunity to certify their Health IT Modules to certification criteria that reference USCDI using USCDI v2 from July 2021 through December 2023. Because we approved a newer version of USCDI—USCDI v3 in July 2023 as part of approved standards for 2023 SVAP—Health IT Modules not already certified to USCDI v1 or v2 may adopt USCDI v3 instead. USCDI v2 will not be available for new and updating certifications via SVAP after December 31, 2023. In this final rule, we have codified USCDI v3 in § 170.213(b), and thus it will not be necessary to use the SVAP process to advance to USCDI v3 after this final rule is effective. In general, these comments are out of scope for this final rule as we did not request feedback on the SVAP program as part of the HTI-1 Proposed Rule.
                    </P>
                    <HD SOURCE="HD3">b. USCDI Standard—Data Classes and Elements Added Since USCDI v1</HD>
                    <P>
                        USCDI v3 includes all data elements defined in USCDI v1 and USCDI v2, as well as additional data elements added in USCDI v3. In the HTI-1 Proposed Rule, we described the data classes and data elements in USCDI v3 that are not included in USCDI v1, as well as any data classes or data elements that were changed through the USCDI update processes when comparing USCDI v3 to USCDI v1 (88 FR 23764). For the overall structure and organization of the USCDI standard, including USCDI v3, we urged the public to consult 
                        <E T="03">www.healthIT.gov/uscdi</E>
                        . We proposed that each of the data classes or data elements listed below be included in the USCDI standard in § 170.213 and be incorporated by reference in § 170.299 as part of our proposal to adopt USCDI v3.
                    </P>
                    <HD SOURCE="HD3">i. Social Determinants of Health (SDOH)</HD>
                    <P>
                        SDOH 
                        <SU>39</SU>
                        <FTREF/>
                         are the conditions in which people live, learn, work, and play, and these conditions affect a wide range of health and quality-of-life risks and outcomes.
                        <SU>40</SU>
                        <FTREF/>
                         In the HTI-1 Proposed Rule, we stated that USCDI v3 includes four SDOH data elements that represent aspects of SDOH data related to the use or purpose of the SDOH data rather than being based on the domain (88 FR 23764). These data elements are SDOH Assessment in the Assessment and Plan of Treatment data class, SDOH Goals in the Goals data class, SDOH Interventions in the Procedures data class, and SDOH Problems/Health Concerns in the Problems data class.
                    </P>
                    <FTNT>
                        <P>
                            <SU>39</SU>
                             See SDOH Toolkit for more information, 
                            <E T="03">https://www.healthit.gov/sites/default/files/2023-02/Social%20Determinants%20of%20Health%20Information%20Exchange%20Toolkit%202023_508.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>40</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/health-it-health-care-settings/social-determinants-health</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters expressed general support for inclusion of SDOH-related data elements in USCDI v3, often noting that the access, exchange, and use of these elements by Health IT Modules certified to particular certification criteria would support the availability of more information and better care for patients, as well as more equitable public health interventions.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the comments expressing support for the inclusion of SDOH-related data elements in USCDI v3 and for recognizing the benefits.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters did not support the inclusion of data elements related to SDOH at this time, stating that the proposed data elements fail to capture a comprehensive view of all SDOH and that there is a lack of standards related to these data elements. Commenters also suggested that SDOH-related data elements only be required as part of USCDI v3 once FHIR-based APIs and implementation guides are available.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their comments voicing concern that SDOH data elements as written in USCDI v3 are not comprehensive enough, lack standards, and should only be required once FHIR-based APIs and implementation guides are available. We note that there are available and applicable standards. Specifically, FHIR US Core 6.1.0 and C-CDA Companion Guide R4.1 support USCDI v3 and align with the SDOH data elements in USCDI v3. We note that both FHIR US Core 6.1.0 and C-CDA Companion Guide R4.1 are incremental updates which address errors and misalignments in their respective prior versions. FHIR US Core 6.1.0 and C-CDA Companion Guide R4.1 have not added any substantial functionality or requirements. We do not believe adoption of FHIR US Core 6.1.0 and C-CDA Companion Guide R4.1 would contribute to a greater implementation burden, and FHIR US Core 6.1.0 and C-CDA Companion Guide R4.1 are the only versions of their respective implementation guides that fully align with and support the complete USCDI v3.
                    </P>
                    <P>
                        As mentioned earlier, we recognize that we proposed different versions of the US Core and C-CDA Companion Guide specifications but stated that we would consider newer versions that align with USCDI v3 (FHIR US Core 6.0.0 and C-CDA Companion Guide R4). However, after the publishing of FHIR US Core 6.0.0 and C-CDA Companion Guide R4, HL7 found errors with how 
                        <PRTPAGE P="1216"/>
                        the guides implemented data elements in USCDI v3 and had to make updates to those specifications to align with USCDI v3 and ensure that USCDI v3 can be implemented in Health IT Modules. Adopting FHIR US Core 6.1.0 and C-CDA Companion Guide R4.1 is necessary for developers of certified health IT to have appropriate implementation guidance to meet the criteria adopted in this final rule that reference USCDI v3. Based on public comments on this and prior rulemakings, we believe that the health IT industry, healthcare standards developers, and health care providers expect and support ONC making such determinations so that the adopted version of standards are the most up-to-date available and are feasible for real world implementation (see, for example, 85 FR 25677 and 25708).
                    </P>
                    <P>
                        In addition, the HL7 Gravity Project's Social Determinants of Health Clinical Care Release 2.0.0 Implementation Guide was published in October 2022.
                        <SU>41</SU>
                        <FTREF/>
                         While the Gravity Project's Social Determinants of Health Clinical Care Implementation Guide does not encompass all possible SDOH aspects, it does define exchange standards for multiple key domains.
                    </P>
                    <FTNT>
                        <P>
                            <SU>41</SU>
                             
                            <E T="03">http://hl7.org/fhir/us/sdoh-clinicalcare/STU2/.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters also urged that SDOH data be protected to ensure the privacy and security of the information, with some commenters urging ONC to adopt granular data segmentation requirements along with USCDI v3.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for noting their concerns regarding SDOH data, specifically the importance of addressing the privacy and confidentiality of sensitive information. The adoption of USCDI v3 sets a new baseline for the capability of Health IT Modules certified to specific certification criteria to capture and exchange data but does not dictate when and how either of those two actions occur. We did not propose and are not adopting privacy protections or standards related to controlling sensitive data that may be represented in USCDI data elements, including granular data segmentation requirements. However, we have adopted a new technical requirement as part of the certification criterion in § 170.315(e)(1) in support of the development and use of technology to enable the HIPAA Privacy Rule's individuals' “right to request a restriction” as discussed in section III.C.10. For more on patient requested restrictions on sharing of their health information, we refer readers to section III.C.10 on modifications to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1) stating that patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. As noted in the HTI-1 Proposed Rule (88 FR 23765), in the 2015 Edition, ONC adopted a certification criterion to enable users of Health IT Modules(s) certified to that criterion with the functionality to electronically capture, modify, and access SDOH data elements—that is information that identifies common SDOH conditions in a standardized manner—in § 170.315(a)(15) social, psychological, and behavioral data (80 FR 62631). These functionalities are intended to support users with the ability to use technology to comply with applicable existing legal requirements or organizational policies that may require such data collection and broader, existing industry interests and efforts to collect and use this data to inform clinical decision-making and improve patient care by looking at the whole patient, including leveraging other types of care such as home and community-based services. ONC supports the use of technology to improve the standardized capture of a set of health data elements to support the healthcare industry's need to electronically capture the underlying data they need or want to collect for healthcare. ONC will continue working with our federal partners in their efforts to educate interested parties, including both health care providers and patients,
                        <SU>42</SU>
                        <FTREF/>
                         regarding the access, exchange, and use of information about patients and the use of certified health IT.
                    </P>
                    <FTNT>
                        <P>
                            <SU>42</SU>
                             See 
                            <E T="03">e.g., https://www.healthit.gov/topic/patient-access-health-records/patient-access-health-records</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested that a base set of SDOH criteria for each of the SDOH elements be required, while optional criteria could be added based on the hospital or provider's specific situation.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for their suggestion. USCDI v3 includes data elements for SDOH Problems/Health Concerns, SDOH Assessment, SDOH Goals, and SDOH Interventions. For the purposes of the Program, developers with Health IT Modules certified to specific certification criteria must support all USCDI v3 data elements, including the SDOH data elements for Problems/Health Concerns, Assessment, Goals, and Interventions. Under these required data elements, those health IT developers may support any of the SDOH domains such as referrals, food insecurity, transportation, and housing security. The USCDI standard is intended to provide a common set of data classes and data elements to support nationwide health information exchange and interoperability, and partial adoption of the USCDI standard would impair its effectiveness in doing so.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters had a variety of recommendations related to including SDOH data elements in USCDI v3. Several comments suggested that ONC partner with standards organizations and others in the industry in developing and implementing SDOH data elements. Commenters also suggested that when developing SDOH data elements, ONC should seek input from patients and advocates representing those with health disparities. Commenters also suggested that ONC work with CMS and state Medicaid agencies on capturing and sharing SDOH data. One commenter suggested aligning SDOH data collection across federal and state healthcare program reporting requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the recommendations related to including SDOH data elements in USCDI v3. We work closely with the HL7 FHIR Gravity Accelerator to develop and implement SDOH data elements. We also support the HL7 Gravity Pilots Affinity Group and support testing through connectathons and pilots. Throughout the spring of 2023, we engaged interested parties and the community in the ONC SDOH Information Exchange Learning Forum, resulting in the creation of an ONC SDOH Information Exchange Toolkit.
                        <SU>43</SU>
                        <FTREF/>
                         In 2021, we funded a Leading Edge Acceleration Project for Referral Management to Address SDOH Aligned with Clinical Care.
                    </P>
                    <FTNT>
                        <P>
                            <SU>43</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/2023-02/Social%20Determinants%20of%20Health%20Information%20Exchange%20Toolkit%202023_508.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>The HL7 FHIR Gravity Accelerator participants include individuals, patients, advocates, representatives from payer organizations, social services organizations, health IT developers, provider associations, and other government participants, including CMS.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters suggested that ONC provide support to providers and their staff to implement SDOH data elements and ensure SDOH data is collected, used, and shared appropriately. Commenters suggested that education and training on SDOH 
                        <PRTPAGE P="1217"/>
                        data elements, including definitions and use cases, is needed for the industry, and several commenters suggested that ONC develop standards, value sets, and mappings related to SDOH data elements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the input regarding the need for support and resources. To support the adoption and implementation of SDOH data elements, ONC published the SDOH Information Exchange Toolkit to further support communities working toward achieving health equity through SDOH information exchange and the use of interoperable, standardized data. The Toolkit is intended to provide information on the exchange of SDOH information to interested parties of all experience levels, as well as identify approaches to advance SDOH information exchange goals. The audience for the Toolkit includes states, payers, health care provider networks, human services providers, and community-based services entities.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter sought clarification regarding the Medicare Promoting Interoperability Program requirements and the SDOH Problems/Health data element and whether there is a need for an option to indicate “None.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the feedback seeking clarification regarding the Medicare Promoting Interoperability Program requirements for the SDOH Problems/Health data element. ONC refers the commenter to CMS for their program requirements.
                    </P>
                    <HD SOURCE="HD3">ii. Care Team Member</HD>
                    <P>In USCDI v1, the Care Team Member data class had one data element to capture all aspects about a care team member. USCDI v3 includes five Care Team Member data elements: Name, Identifier, Role, Location, and Telecom.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters specifically supported the inclusion in USCDI v3 of the Care Team Member Name and Identifier data elements. However, several commenters had concerns about the Care Team Member data elements. These commenters suggested removal of the Care Team Member Name and Identifier data elements to protect providers or, alternatively, to let providers opt out of having their information included and noted that providers may be at risk of personal harm if their identity is known. Other commenters noted that without standards, organizations will implement the data elements differently. One commenter recommended that a value set and coding be provided for the Care Team Member Role data element.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the comments regarding Care Team Member Name, Role and Identifier data elements. We work with the HL7 community to develop vocabulary applicable to USCDI data elements to ensure standard implementation of these data elements. In addition, we note that the USCDI v3 is a standard as a whole and has been adopted in whole, as proposed. As conveyed elsewhere in our responses, the adoption of USCDI v3 sets a new baseline for the capability of Health IT Modules certified to particular certification criteria to capture and exchange such data but does not dictate when and how either of those two actions occur. Specifically, in the Program, we establish requirements for Health IT Modules to enable a user to capture or exchange data. We do not establish requirements in the Program for an entity to use a certified Health IT Module or for the user of a Health IT Module to capture or record specific data.
                    </P>
                    <HD SOURCE="HD3">iii. Clinical Notes</HD>
                    <P>For the data element Discharge Summary Note in the Clinical Notes data class, we specified additional requirements in USCDI v3 including admission and discharge dates and locations, discharge instructions, and reason(s) for hospitalization, which are also required elements in the “transitions of care” certification criterion (§ 170.315(b)(1)).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments supporting the Clinical Notes data class and data elements, including Discharge Summary Note. One commenter noted that standardizing the presentation of this information will improve consistency and reliability. Another commenter focused on the specified Logical Observation Identifiers Names and Codes (LOINC®) codes and recommended linking them to International Classification of Diseases, Tenth Revision, Clinical Modification (ICD-10-CM) -Z codes and/or SNOMED-CT, which represent concepts rather than specific questions and answers, and recommended considering one-to-many bindings. One commenter sought clarification regarding whether ONC certification would require support for both structured and unstructured narrative findings.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the comments on the Clinical Notes data class and data elements regarding standardization. Health IT developers certifying Health IT Modules to certification criteria that reference USCDI v3 must align with the applicable vocabulary standards as defined in USCDI v3 and with the requirements in the C-CDA Companion Guide R4.1 and FHIR US Core 6.1.0 that list concept codes from the LOINC Document Ontology to identify the note type. Many certification criteria reference the USCDI standard, which comprises either structured or unstructured narrative notes.
                    </P>
                    <HD SOURCE="HD3">iv. Clinical Tests</HD>
                    <P>USCDI v3 includes a data class for Clinical Tests, which has two data elements, Clinical Test and Clinical Test Result/Report. This is a new data class as compared to USCDI v1.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments expressing concerns regarding the Clinical Tests data class and data elements. One commenter expressed concerns about the Clinical Tests Results/Report data element, stressing that human interpretation is needed and that it could be dangerous to send test results without “normal” or “abnormal” indicators, or a reference range. One commenter sought clarification regarding whether ONC will require support for both structured and unstructured narrative findings. One commenter noted that the availability of clinical tests in EHR systems varies substantially.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments regarding concerns about how the Clinical Tests data elements are implemented. The two data elements represent the minimum information necessary to convey patient data for non-laboratory and non-diagnostic imaging tests, such as electrocardiograms and visual acuity. We agree with the commenter that supplemental data such as “normal,” “abnormal,” or reference ranges provide valuable information. However, the USCDI v3 is a published standard at 
                        <E T="03">www.healthit.gov/uscdi</E>
                         and thus it is not possible to add new data elements to USCDI v3 through the rulemaking process or other means at this time. We direct commenters to the USCDI website available at 
                        <E T="03">https://www.healthit.gov/uscdi</E>
                         where the public is invited to enter comments on leveled data elements or submit new data elements for consideration in future version of USCDI. Health IT developers are encouraged to work with their customers to exchange data that adds value. The Clinical Test data element must be represented with a LOINC® code to indicate the specific test performed or planned. The Clinical Test Result/Report data element may be structured and represented using a code set such as SNOMED CT U.S. Edition, or unstructured and represented with free text. The Program does not require 
                        <PRTPAGE P="1218"/>
                        the use of standardized vocabularies for Clinical Test Result/Report.
                    </P>
                    <P>ONC acknowledges that clinical test availability varies within and across EHR systems. However, Health IT Modules certified to criteria that reference the USCDI standards in § 170.213 must have the capability to exchange clinical test data.</P>
                    <HD SOURCE="HD3">v. Diagnostics Imaging</HD>
                    <P>USCDI v3 includes the Diagnostic Imaging data class and its two elements: Diagnostic Imaging Test and Diagnostic Imaging Report. This is a new data class as compared to USCDI v1.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments on the Diagnostic Imaging data class noting that many specialty health IT systems may not integrate with or support imaging services, and a requirement to support this data class could be infeasible for some systems or result in unused capabilities.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. We understand that many specialty health IT systems do not integrate with or support imaging services. The data elements in the Diagnostic Imaging data class are not specific to the actual images that may be housed or supported in an image storing system, but rather are based on types of diagnostic imaging referenced by LOINC® codes and the interpreted imaging test results in a report. USCDI is not specific to a setting of care, a healthcare specialty, or a specific category of health IT user; the standard provides a common set of data classes and data elements that can be used for nationwide, interoperable health information exchange. To ensure interoperability for the core set of data in the USCDI, it is important for developers of certified health IT to support the complete USCDI where required for health IT certification criteria in the Program. To the extent that such specialty health IT systems are not certified to certification criteria that reference § 170.213, then they would not have to support this data class.
                    </P>
                    <HD SOURCE="HD3">vi. Encounter Information</HD>
                    <P>USCDI v3 includes the Encounter Information data class, which includes five data elements: Encounter Type, Encounter Diagnosis, Encounter Time, Encounter Location, and Encounter Disposition. This is a new data class as compared to USCDI v1.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed specific agreement and support of the Encounter Information data class. Several comments expressed concerns, including regarding a lack of standards. One commenter recommended only adopting the Encounter Diagnosis data element since it does have a standard. One commenter expressed concern that Encounter Information would identify information about pregnancy termination services that could be misused and lead to administrative or criminal investigations of patients and providers. Another commenter sought confirmation regarding whether inpatient encounters need to be included and suggested that they be included in a final rule.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have reviewed the comments regarding the Encounter Information data class and concerns around the lack of standards. The USCDI v3 data classes and data elements apply to inpatients and outpatients and define applicable vocabulary standards where appropriate. The Encounter Diagnosis data element references the SNOMED CT U.S. Edition and ICD-10-CM vocabulary standards. Regarding comments on privacy and security of Encounter Information and related services, we note the adoption of USCDI v3 sets a new baseline for the capability of Health IT Modules certified to particular certification criteria to capture and exchange data but does not dictate when and how either of those two actions occur.
                    </P>
                    <HD SOURCE="HD3">vii. Health Insurance Information</HD>
                    <P>USCDI v3 includes the Health Insurance Information data class, which provides an opportunity for health IT to capture and exchange key elements of healthcare insurance coverage. This is a new data class as compared to USCDI v1. This data class includes seven data elements: Coverage Status, Coverage Type, Relationship to Subscriber, Member Identifier, Subscriber Identifier, Group Identifier, and Payer Identifier.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters expressed support for the Health Insurance Information data class. Comments included that it would be vital for emergency medical services (EMS) providers to receive reimbursement and that it will open opportunities for patients and providers to use beneficial apps, such as those related to cost barriers and administrative transactions.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support of the Health Insurance Information data class and for recognizing the potential benefits.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters expressed concern or did not support the Health Insurance Information data class. Several commenters stated that the data elements needed more standardization before they should be required, and that it was unreasonable to include this data class because there are no related standards yet. One commenter stated that the Health Insurance Information data class is problematic because there is no guidance about how to align this proposed standard with the proposed US Core IG v5.0.1 that payers would be required to adopt via the Interoperability and Prior Authorization Proposed Rule (87 FR 76238). The commenter stated that ONC's proposal does not align with the changes proposed in the Interoperability and Prior Authorization Proposed Rule. Commenters also stated that prior authorization standards were needed for payers to see value in this data class. Additionally, commenters expressed concern that most health IT systems seeking certification would need to rely on third-party systems to support documentation and storage of health insurance data. Commenters also stated that ONC should not add data elements to the USCDI that duplicate processes housed in practice management systems. Several commenters stated that USCDI v3 should not be required until the Health Insurance Information data class is revised, or that USCDI v3 should be adopted without the Health Insurance Information data class included. Commenters also stated that the Health Insurance Information data class should not have to be shared until CMS clarifies which data elements do not have to be shared through the Payer-to-Payer API to avoid the exchange of competitively sensitive information.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have considered the comments expressing concern about the Health Insurance Information data class. We do not agree that there are no related standards for these data elements, as HL7 FHIR US Core and the C-CDA Companion Guide support the Health Insurance Information data elements and include references to standard vocabulary where available and in use. Regarding alignment with requirements proposed by CMS in the Interoperability and Prior Authorization Proposed Rule, we refer readers to CMS' proposals in the Interoperability and Prior Authorization Proposed Rule to allow payers to use updated versions of standards in § 170.215, subject to certain conditions including approval for use by the National Coordinator (87 FR 76315). We also note that in the Interoperability and Prior Authorization Proposed Rule, CMS has proposed to allow flexibility for use of a version of the USCDI standard in § 170.213 (87 FR 76250) where proposed payer API requirements reference the USCDI, which will include USCDI v3 under our finalized policy. We further disagree 
                        <PRTPAGE P="1219"/>
                        with the concerns reflected in the comments about the burden that would be associated with sharing this data and believe these comments may not accurately reflect what is expected from the USCDI v3 data elements. The data elements in this data class are to exchange information about whether a patient has insurance coverage, and the type of coverage. Also included are elements that provide information about the plan. The Health Insurance Information data elements do not include any claims specific information. Additionally, we recognize that this information may or may not originate in an EHR, however Health IT Modules certified to certification criteria that reference § 170.213 must be able to capture and exchange the values when available.
                    </P>
                    <P>
                        Regarding the comment about this data only being valuable with respect to prior authorization standards, we note that such standards may be adopted in the future and believe that this information can provide substantial value at present by supporting the availability of data about coverage that is important for health care providers to understand a patient's situation. We recently sought comment through an RFI titled “Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria” (87 FR 3475), which appeared in the January 24, 2022 issue of the 
                        <E T="04">Federal Register</E>
                        , on how updates to the Program could support electronic prior authorization. We have reviewed comments, and this information may be used to inform a future rulemaking related to the ONC Health IT Certification Program and electronic prior authorization. We will continue to work with CMS to ensure alignment with our rules.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters also expressed privacy concerns regarding the Health Insurance Information data class. Commenters suggested that ONC revise the data class to protect patient privacy and that ONC should remove data elements that provide personally identifiable information not supportive of patient care, such as “group identifier.” Commenters also expressed concern about the inclusion of financial data in the USCDI, the sharing of claim-level payment information and the disclosure of confidentially negotiated rates.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As we have noted in similarly themed comments, the adoption of USCDI v3 sets a new baseline for the capability of Health IT Modules certified to particular certification criteria to capture and exchange data but does not dictate when and how either of those two actions occur. Further, the concerns expressed related to financial data including claim-level payment and negotiated rates are not within scope of the HTI-1 Proposed Rule because USCDI v3 does not include any financial, claim level, or negotiated rate data elements.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters suggested that the data class should focus on data elements related to whether a person has insurance coverage, the type of coverage, and which payers are covering the patient. Other commenters suggested that the data class should be revised to focus on sharing information that can be collected based on national standards. Commenters also stated that vendors use different health insurance payer identification numbers, making it challenging to match records, and that ONC should work with the industry to adopt a single source for payer identification. One commenter recommended including both medical insurance and prescription insurance as part of the data elements, and another comment recommended that ONC adopt the data elements included in the CARIN IG for Blue Button.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the additional suggestions. The data elements in the Health Insurance Information class are to exchange information about whether a patient has insurance coverage, and the type of coverage. Also included are elements that provide information about the plan.
                    </P>
                    <P>
                        The USCDI v3 is a published standard at 
                        <E T="03">www.healthit.gov/uscdi</E>
                         and thus it is not possible to add new data elements to USCDI v3 through the rulemaking process or other means at this time. We direct commenters to the USCDI website available at 
                        <E T="03">www.healthit.gov/uscdi</E>
                         where the public is invited to enter comments on leveled data elements or submit new data elements for consideration in future versions of USCDI.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters sought clarification regarding the Coverage Status data element and if it should indicate whether and which type of health insurance a patient has, rather than if specific services are covered. One commenter sought clarification for why the value set for Coverage Type data element was not a required standard in USCDI v3. Commenters also sought clarification regarding whether health insurance includes both medical and prescription insurance.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The Health Insurance data class is intended to capture data related to an individual's insurance coverage for healthcare including medical and prescription insurance. Coverage Status is defined in USCDI v3 as the presence or absence of healthcare insurance, whereas Coverage Type is designed to communicate the category of healthcare payer (
                        <E T="03">e.g.,</E>
                         Medicare, Commercial, Managed Care—PPO). ONC refers implementers to the US Core and C-CDA implementation guides for guidance on specific value sets. For future versions of USCDI, we encourage interested parties to provide feedback for applicable vocabulary standards, for the Coverage Type and Coverage Status data elements during an open comment period at 
                        <E T="03">https://www.healthit.gov/uscdi.</E>
                    </P>
                    <HD SOURCE="HD3">viii. Health Status Assessments</HD>
                    <P>USCDI v3 includes a data class called Health Status Assessments, which contains four new data elements: Disability Status, Mental/Cognitive Status, Functional Status, and Pregnancy Status. This is a new data class as compared to USCDI v1. In USCDI v3, the Health Status Assessments data class also includes two data elements that have been recategorized, Health Concerns and Smoking Status, which were previously part of different data classes in USCDI.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concerns about the Health Status Assessment data class. One commenter noted that Health Status Assessments often vary from provider to provider and that requiring these data elements from non-standardized forms by the proposed deadline is not possible. One commenter noted that it is not clear how the USCDI data elements apply to mental/behavioral health and substance use treatment data.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters and acknowledge that assessments often vary from provider to provider. The USCDI data elements in this data class reference applicable vocabulary standards, including LOINC and SNOMED CT U.S. Edition, to identify the assessment and related questions which may identify not only the assessment or survey instrument, but may also allow for understanding the semantics of the assessment data. The USCDI v3 includes a Mental/Cognitive Status data element to support the exchange of mental/behavioral health data. There are new data elements in USCDI v4 that capture Alcohol Use and Substance Use assessments. We clarify that USCDI v4 is not being adopted as a standard in this final rule. Additionally, USCDI v4 is not available through SVAP at this time. Generally, approved SVAP versions of standards are announced in June each year and 
                        <PRTPAGE P="1220"/>
                        become effective for Program use after a 60-day period.
                        <SU>44</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>44</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/2023-07/2023_SVAP_Fact_Sheet.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of the comments on the Health Status Assessment data class were related to the Pregnancy Status data element. One commenter expressed support for including Pregnancy Status as a data element, but most comments expressed concerns about Pregnancy Status, including regarding legal implications for providers and that sharing this information in patients' records without their express consent could create real dangers. Some commenters recommended reconsidering this data element given the increased criminalization of reproductive health and pregnancy-related care. Commenters suggested delaying the inclusion of this data element until patient requested restrictions could be fully operationalized. Commenters also noted a lack of standards around this data element and stated that without standards, incompatible data could be entered for Pregnancy Status, and recommended against including it as a data element until there is a defined standard. One commenter recommended also including Pregnancy Intention Screening as a data element.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments regarding privacy concerns expressed above. The adoption of USCDI v3 sets a new baseline for the capability of Health IT Modules certified to particular certification criteria to capture and exchange data but does not dictate when and how either of those two actions occur. For more on patient requested restrictions on sharing of their health information, we refer readers to section III.C.10 on modifications to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1), stating patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213.
                    </P>
                    <P>
                        The USCDI v3 is a published standard at 
                        <E T="03">www.healthit.gov/uscdi</E>
                         and thus it is not possible to add new data elements to USCDI v3 through the rulemaking process or other means at this time. We direct commenters to the USCDI website available at 
                        <E T="03">www.healthit.gov/uscdi</E>
                         where the public is invited to enter comments on leveled data elements or submit new data elements for consideration in future versions of USCDI. Commenters are directed to the FHIR US Core 6.1.0 and C-CDA Companion Guide R4.1 for guidance on how to implement the Pregnancy Status data element.
                    </P>
                    <HD SOURCE="HD3">ix. Laboratory</HD>
                    <P>USCDI v3 includes Specimen Type and Result Status data elements, which have been added to the USCDI Laboratory data class to address public health reporting priorities.</P>
                    <P>We did not receive comments to specifically respond to with clarifications.</P>
                    <HD SOURCE="HD3">x. Medications</HD>
                    <P>USCDI v3 includes Dose, Dose Unit of Measure, Indication, and Fill Status data elements, which have been added to the Medications data class in response to public feedback. These data elements are necessary for certain CMS reporting programs and are also critical to certain ONC certification criteria (including the “electronic prescribing certification” criterion at § 170.315(b)(3)).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several comments expressed concern about the lack of standards for data elements in the Medications data class, including Medications, Indication, and Fill Status. One comment noted that Fill Status data is generally maintained by pharmacy systems and many systems seeking certification would not natively support documentation and storage of this information. One comment stated that USCDI v3 is not clear regarding what must be included for the Medications data element and that more specificity could improve patient care and safety.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The Medications data element includes both RxNorm and NDC as applicable vocabulary standards in USCDI v3. The HL7 FHIR US Core Implementation Guide and C-CDA Companion Guide for USCDI v3 have defined terminology bindings for Indication to include value sets drawn from both SNOMED CT U.S. Edition and ICD-10-CM. Regarding the utility of including Fill Status in the USCDI v3, we recognize that this information may or may not originate in an EHR, however certified health IT with Health IT Modules certified to particular certification criteria that reference § 170.213 must be able to capture and exchange the value when it is available.
                    </P>
                    <HD SOURCE="HD3">xi. Patient Demographics/Information</HD>
                    <P>Based on submissions and comments during the USCDI update processes described above, we changed or added data elements in the Patient Demographics/Information data class. USCDI v3 includes data elements Sexual Orientation and Gender Identity, which have been added to the USCDI Patient Demographics/Information data class. As described in the HTI-1 Proposed Rule, we previously adopted standards for Sexual Orientation in the demographics criterion in § 170.315(a)(5)(i)(D) and for Gender Identity in the demographics criterion in § 170.315(a)(5)(i)(E) that included requirements to code Sexual Orientation and Gender Identity according to the adopted SNOMED CT® U.S. Edition codes and HL7 Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor, as referenced § 170.207(o)(1) and § 170.207(o)(2), respectively (88 FR 23766). We proposed to remove the requirement to use specific codes for representing Sexual Orientation and Gender Identity and have removed the codes as applicable vocabulary standards from USCDI v3. We proposed that certified health IT with Health IT Modules certified to particular certification criteria that reference § 170.213 would be required to be capable of representing Sexual Orientation and Gender Identity in SNOMED CT® U.S. Edition when such information is exchanged as part of USCDI. We stated in the HTI-1 Proposed Rule that we believe it is best to let the health IT community develop the list of appropriate values for Sexual Orientation and Gender Identity, whether through implementation specifications or developing additional codes in SNOMED CT® U.S. Edition (88 FR 23766).</P>
                    <P>
                        As described in the HTI-1 Proposed Rule, we have recharacterized the USCDI data element Sex (Assigned at Birth) to Sex (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). We also proposed to no longer require the use of specific code sets for representing Sex and have removed the codes from USCDI v3. We proposed that certified health IT with Health IT Modules certified to certification criteria that reference § 170.213 would be required to be capable of representing Sex in SNOMED CT when such information is exchanged as part of USCDI. We proposed to adopt the same changes for relevant certification criteria that reference these 
                        <PRTPAGE P="1221"/>
                        standards (see sections III.C.8 and III.C.9).
                    </P>
                    <P>In the HTI-1 Proposed Rule, we noted efforts to develop a clinically meaningful way for identifying a patient's sex from observable information that may be suitable for clinical care, including the development of a new data element Sex for Clinical Use, and sought public comment on this concept and approach (88 FR 23766). In addition, as noted in our proposals to the “patient demographics and observations” certification criterion in § 170.315(a)(5), we proposed to adopt the same changes for relevant certification criteria that reference these standards (see sections III.C.8 and III.C.9).</P>
                    <P>
                        As discussed in the HTI-1 Proposed Rule, a new standard for patient addresses, the Unified Specification for Address in Health Care (US@),
                        <SU>45</SU>
                        <FTREF/>
                         emerged and was released in 2022 (88 FR 23767). After receiving broad support from the public, ONC has incorporated the Project US@ Technical Specification version 1 as the applicable standard for Current Address and Previous Address in USCDI v3.
                    </P>
                    <FTNT>
                        <P>
                            <SU>45</SU>
                             
                            <E T="03">https://oncprojectracking.healthit.gov/wiki/pages/viewpage.action?pageId=180486153.</E>
                        </P>
                    </FTNT>
                    <P>Also as discussed in the HTI-1 Proposed Rule, USCDI v3 includes six data elements added to the USCDI Patient Demographics/Information data class: Related Person's Name, Related Person's Relationship, Date of Death, Occupation, Occupation Industry, and Tribal Affiliation.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters explicitly expressed support for the Patient Demographics/Information data class, noting that this will improve healthcare quality, enhance communication, bolster cultural competency, and support the ability of providers to gather and exchange the information needed to make the best care plans for their patients.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support of the Patient Demographics/Information data class and for noting the potential benefits.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters had concerns about the Patient Demographics/Information data class, including that it was not reasonable to require the full data class. Additionally, comments included recommendations for ONC with respect to the Patient Demographics/Information data class. Comments recommended aligning deadlines with the availability of FHIR-based APIs to ensure consistency across interested parties and aligning the USCDI Patient Demographics/Information data class with CMS definitions of the included data elements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We receive submissions and comments from federal partners, including CMS, on the USCDI and will continue to work towards alignment where appropriate with these partners. With respect to the suggestions regarding flexibility in supporting USCDI v3 data classes and data elements for purposes of the Program, we decline to allow developers to be selective in which USCDI v3 data classes and data elements they support for purposes of the Program. Because the USCDI standard is intended to provide a common set of data classes and data elements in support of nationwide health information exchange, partial adoption of the USCDI standard would impact the effectiveness of the standard and impede interoperability.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Specific comments about data elements stated that standards should be included to restrict date formats for Date of Birth and Date of Death data elements, and that Previous Name and Tribal Affiliation data elements should not be included in USCDI v3 until there are standards for them. One commenter asked for clarification on whether detailed race standards or free text fields should be used for Tribal Affiliation.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the feedback on the lack of standards for the Date of Birth and Date of Death data elements. We direct commenters to the HL7 FHIR US Core Implementation Guide and the C-CDA Companion Guide when an applicable standard is not identified in USCDI. In addition, these implementation guides provide guidance for exchanging Previous Name and Tribal Affiliation, the latter of which includes a vocabulary binding to a harmonized value set.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters addressed the Sexual Orientation and Gender Identity (SOGI) and Sex data elements. Many of those commenters expressed support for including SOGI data elements, for removal of the requirement to use specific codes for representing SOGI, and for updating SOGI codes with SNOMED CT. Some of these commenters noted that this would reduce burden and would facilitate identifying disparities and improving outcomes for the LGBTQ+ population.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the feedback in support of the Sexual Orientation, Gender Identity, and Sex data elements and related requirements and standards, and for recognizing the potential benefits.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concerns related to the SOGI data elements, including that best practices around SOGI data are not well established and that there could be unintended confusion around the terms. Commenters also stressed the need for standardized codes related to SOGI, the importance of industry collaboration, and the value of education on SOGI data elements and use cases. One commenter noted that patients are historically reluctant to answer questions on sexual identity and this may lead to lower accuracy. One commenter stated that the health IT industry will not coalesce around value sets for Sex, Sexual Orientation and Gender Identity data elements and urged ONC to create them. Commenters also noted that several existing definitions within the proposed standards for SOGI expire on December 31, 2025, and recommended aligning deadlines.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the detailed comments. We defined SNOMED CT, U.S. Edition as the vocabulary standard for Sex, Sexual Orientation, and Gender Identity in USCDI v3. We collaborated with HL7, and the HL7 Gender Harmony Project team to update the US Core Implementation Guide and C-CDA Companion Guide with references to value sets with specific SNOMED CT U.S. Edition concepts. We work closely with federal partners to promote quality data capture and storage practices using standard terminology. We encourage providers to work with their patients to understand how and when this data is valuable for patient care and to address the situation where a patient may be reluctant to share information.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that changing Sex (assigned at birth) to Sex would lead to inconsistency and that it would be preferable to define a series of specific data elements with clear definitions related to this data class. One commenter sought clarification that under USCDI v3 developers should continue exchanging the same data from their systems that is currently being exchanged as the Sex (assigned at birth) data element to comply with requirements for the Sex data element.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the input regarding the Sex data element in USCDI v3 and concerns regarding the update from Sex (Assigned at Birth) in USCDI v2 to Sex in USCDI v3. We, along with the HL7 community recognized that Sex (Assigned at Birth) has been used to represent different concepts not always associated with the value assigned at time of birth such as clinically relevant sex for laboratory tests or diagnostic imaging, and administrative sex recorded on birth certificates and health forms. The values 
                        <PRTPAGE P="1222"/>
                        used for each instance may not be the same for a given patient. Furthermore, the value set referenced in earlier versions of USCDI for Sex (Assigned at Birth) does not include all possible values that represent sex. We therefore removed the reference to the limited value set previously used and expanded the applicable vocabulary standard to the SNOMED CT U.S. Edition code set. ONC worked closely with HL7 Structured Documents and US Core teams to update the US Core Implementation Guide and the C-CDA Companion Guide to distinguish between Sex (Assigned at Birth) and Sex as separate data elements. It is ONC's intent that developers continue exchanging the same data from their systems that is currently being exchanged as Sex (Assigned at Birth) and additionally exchange the USCDI v3 Sex data element.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         In the HTI-1 Proposed Rule, we stated that we welcomed public comment on the development and inclusion in future standards of a new data element Sex for Clinical Use (88 FR 23766). We received several comments in support of including a Sex for Clinical Use data element in future versions of USCDI, generally because of the perceived benefits. One commenter opposed inclusion of Sex for Clinical Use as a data element in USCDI without further consultation with transgender and intersex communities. However, most of the comments about Sex for Clinical Use related to proposals regarding the Sex for Clinical Use data element in the “patient demographics and observations” criterion.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for these suggestions. Sex for Clinical Use may be considered for inclusion as a data element in a future version of USCDI. We received comments related to Sex for Clinical Use as it relates to the “patient demographics and observations” certification criterion, and we discuss those comments in section III.C.8 of this final rule concerning the “patient demographics and observations” certification criterion in § 170.315(a)(5).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         There were several comments related to the Race and Ethnicity data elements. Commenters expressed concerns about upgrading to the 2022 version of the Centers for Disease Control and Prevention (CDC) Race and Ethnicity code sets because this would add burden to the industry and recommended only adding codes and not changing existing ones. Commenters requested clarification on why this change was needed and the benefits. Commenters also noted that ONC should follow efforts by the Office of Management and Budget (OMB) regarding adoption of new race and ethnicity data standards.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the input regarding the Race and Ethnicity data elements. We did not propose updating to the 2022 version of the Centers for Disease Control and Prevention (CDC) Race and Ethnicity code set at this time as the 2022 version of CDC Race and Ethnicity code set has not been released. We assure commenters that we follow efforts by OMB regarding adoption of new race and ethnicity standards.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters asked for additional guidance, including on how data for the Patient Demographics/Information data class is collected and used, and on terminology related to SOGI. One commenter requested that ONC clarify how interested parties should address conflicting information among SOGI data elements due to disparities in elements and collection. One comment stated that ONC should encourage healthcare organizations to offer the term “nonbinary” as a Gender Identity data element field.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the feedback. We do not dictate when and how capture and exchange of USCDI data elements occur, nor how conflicting information may be reconciled. We also do not require specific concepts, such as “nonbinary,” from the applicable vocabulary standard, SNOMED CT U.S. Edition for Gender Identity, and instead defer to the HL7 FHIR US Core Implementation Guide, HL7 v2 and C-CDA Companion Guide to declare value sets appropriate for use.
                    </P>
                    <HD SOURCE="HD3">xii. Problems</HD>
                    <P>As discussed in sub-section i of this section, USCDI v3 includes the SDOH Problems/Health Concerns data element added to the prior USCDI Problems data class. In addition, USCDI v3 includes Date of Diagnosis and Date of Resolution data elements added to the prior USCDI Problems data class to include timing elements for recorded and maintained problem lists within electronic health records.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A couple of commenters noted a lack of standards for the Date of Diagnosis, Date of Resolution, and Problems data elements. Commenters stated that the lack of standards constricting date formats impacts interoperability, and that the Problems data element should be able to indicate a degree of importance.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the input regarding the lack of standards for Date of Diagnosis, Date of Resolution, and Problems data elements. While the USCDI v3 does not identify applicable vocabulary standards for the data elements, the HL7 FHIR US Core Implementation Guide and C-CDA Companion Guide define the allowable date formats.
                    </P>
                    <P>
                        Addressing the comment about indicating a degree of importance for a Problem, the USCDI v3 is a published standard at 
                        <E T="03">www.healthit.gov/uscdi</E>
                         and thus it is not possible to add new data elements to USCDI v3 through the rulemaking process or other means at this time. We direct commenters to the USCDI website available at 
                        <E T="03">www.healthit.gov/uscdi</E>
                         where the public is invited to enter comments on leveled data elements or submit new data elements for consideration in future versions of USCDI.
                    </P>
                    <HD SOURCE="HD3">xiii. Procedures</HD>
                    <P>USCDI v3 includes the Reason for Referral data element added to the prior USCDI Procedures data class. As discussed in sub-section i of this section, the USCDI v3 also includes the SDOH Interventions data element added to the prior USCDI Procedures data class.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter on the Procedures data class recommended that USCDI v3 specify that CDT is the applicable standard for technology developed to record dental procedures.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for the comment and note that the Code on Dental Procedures and Nomenclature (CDT) is included in USCDI v3 as an applicable standard in the USCDI v3 Procedures data element in the Procedures Data Class and may be used when exchanging dental procedures.
                    </P>
                    <HD SOURCE="HD3">xiv. Updated Versions of Vocabulary Standard Code Sets</HD>
                    <P>In the 2015 Edition Final Rule, we established a policy for minimum standards code sets that update frequently throughout a calendar year at 80 FR 62612, and we have listed several standards as minimum standards code sets in 45 CFR part 170 subpart B. As with all adopted minimum standards code sets, health IT can be certified to newer versions of the adopted baseline version minimum standards code sets for purposes of certification, unless the Secretary specifically prohibits the use of a newer version (see § 170.555 and 77 FR 54268). In USCDI v3, we included the versions of the minimum standards code sets available when we published USCDI v3. We have adopted the minimum standards code sets we proposed in the HTI-1 Proposed Rule.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters recommended that HL7, LOINC, SNOMED CT U.S. Edition, and RxNorm 
                        <PRTPAGE P="1223"/>
                        vocabulary bindings be added to the USCDI criteria in the final rule.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the comments related to vocabulary and vocabulary bindings in USCDI. USCDI v3 includes required and optional applicable vocabulary standards with references to code sets for data elements where an encoded value is expected and where a code set has been identified and is in use. This general binding to a code system may be further refined in the HL7 implementation guides.
                    </P>
                    <HD SOURCE="HD3">xv. Unique Device Identifier(s) for a Patient's Implantable Device(s)</HD>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters specifically supported Unique Device Identifier(s) for a Patient's Implantable Device(s) as a data class and data element in USCDI v3. One commenter encouraged ONC to include this data element in all information exchanges and to work with CMS to tie Unique Device Identifier codes to payment for devices.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the comments regarding Unique Device Identifier(s) for a Patient's Implantable Device(s). Regarding requests that ONC work with CMS on alignment, we assure commenters that we work closely with CMS across multiple programs and initiatives to align program requirements and deadlines and will continue to do so in the future.
                    </P>
                    <HD SOURCE="HD3">xvi. Vital Signs</HD>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern that without dates and times, vital signs information is not meaningful and potentially dangerous.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the comments and understand the concern. The HL7 FHIR US Core Implementation Guide (both the prior and updated versions) adopted in § 170.215(b)(1) and incorporated by reference in § 170.299 and the HL7 C-CDA R2.1 base standard adopted in § 170.205(a)(4) and incorporated by reference in § 170.299 require dates and times when exchanging vital signs.
                    </P>
                    <P>After consideration of all comments regarding the data classes and data elements in USCDI v3, we have finalized our adoption of USCDI v3 in § 170.213(b) as proposed. We have extended the date USCDI v1 expires as a standard for use in the Program to January 1, 2026.</P>
                    <HD SOURCE="HD3">2. C-CDA Companion Guide Updates</HD>
                    <P>We proposed to adopt the HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 3—US Realm in § 170.205(a)(6) (“C-CDA Companion Guide R3”). The C-CDA Companion Guide R3 provides supplemental guidance and additional technical clarification for specifying data in the C-CDA Release 2.1 for USCDI v2. We stated that if the C-CDA Companion Guide Release 4 (C-CDA Companion Guide R4) is published before the date of publication of this final rule, it would be our intention to consider adopting the updated C-CDA Companion Guide R4 that provides guidance and clarifications for specifying data in USCDI v3 in § 170.205(a)(6), since we proposed to adopt USCDI v3 as the baseline (88 FR 23767).</P>
                    <P>As mentioned above, HL7® has been updating the C-CDA Companion Guide to accommodate the new data classes and data elements in each USCDI version. To allow developers to voluntarily update to USCDI v2, ONC included the C-CDA Companion Guide R3 in the SVAP Approved Standards List for 2022. ONC released the SVAP Approved Standards List for 2022 in June 2022. We stated in the HTI-1 Proposed Rule that we anticipated that the C-CDA Companion Guide R4 would support updates included in the proposed USCDI v3 and that the adoption of the C-CDA Companion Guide R4 would align with our goal to increase the use of consistently implemented standards among health IT developers and improve interoperability. We proposed to adopt the C-CDA Companion Guide R3 as a standard in § 170.205(a)(6) and incorporate it by reference in § 170.299. We stated that if the C-CDA Companion Guide R4 is available at the time of publication of this final rule, we would consider adopting the C-CDA Companion Guide R4 in § 170.205(a)(6), which would support the updates included in proposed USCDI v3 (88 FR 23767).</P>
                    <P>Consistent with our proposals in sections III.A and III.C.11, we proposed to revise § 170.205(a)(5) to add that the adoption of the standard in § 170.205(a)(5) expires on January 1, 2025. Developers of certified health IT with Health IT Modules certified to particular certification criteria that reference § 170.205(a)(5) would have to update those Health IT Modules to § 170.205(a)(6) and provide them to customers by January 1, 2025. We clarified that under this proposal, for the time period up to and including December 31, 2024, HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 would remain applicable as the minimum version required in the Program.</P>
                    <P>Further, we proposed that Health IT Modules certified to the particular certification criteria below would need to update to the HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 in § 170.205(a)(6) by January 1, 2025:</P>
                    <P>• “transitions of care” (§ 170.315(b)(1)(iii)(A));</P>
                    <P>• “clinical information reconciliation and incorporation” (§ 170.315(b)(2)(i), (ii), and (iv));</P>
                    <P>• “care plan” (§ 170.315(b)(9)(ii));</P>
                    <P>• “view, download, and transmit to 3rd party” (§ 170.315(e)(1)(i)(A) and (B));</P>
                    <P>• “consolidated CDA creation performance” (§ 170.315(g)(6)(i)); and</P>
                    <P>• “application access—all data request” (§ 170.315(g)(9)(i)).</P>
                    <P>For the purposes of meeting that compliance date, we stated that we expected health IT developers to update their certified health IT without new mandatory testing and notify their ONC-ACB on the date at which they have reached compliance. Developers would also need to factor these updates into their next real world testing plan (88 FR 23767 through 23768).</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters supported the adoption of the HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 as proposed in § 170.205(a)(6). Many of the comments also noted support for the adoption of C-CDA Companion Guide Release that aligns with USCDI v3 if published before the date of publication of this final rule. Comments supporting this proposal noted that incorporating newer versions of the C-CDA standard will improve interoperability of clinical data.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for support of our proposals and for recognizing potential benefits expand interoperability for clinical information shared via structured clinical notes. We also appreciate commenters who recommended adoption of the most recent version of C-CDA Companion Guide. After the publication of C-CDA Companion Guide R4, HL7 found errors with how the guide implemented data elements in USCDI v3 and had to make updates to the specification to align with USCDI v3 and ensure that USCDI v3 can be implemented in certified Health IT Modules. We note that C-CDA Companion Guide R4.1 has not added any substantial functionality or requirements beyond C-CDA Companion Guide R4. Therefore, we do not believe adoption of C-CDA Companion Guide R4.1 would contribute to a greater implementation burden, and C-CDA Companion Guide R4.1 is the only version of the C-CDA 
                        <PRTPAGE P="1224"/>
                        Companion Guide that fully aligns with and supports the complete USCDI v3. Given the support of the commenters to adopt the most recent version of the C-CDA Companion Guide that aligns with USCDI v3, we have finalized adoption of C-CDA Companion Guide R4.1, which was published in June 2023, in § 170.205(a)(6).
                    </P>
                    <P>Adopting the C-CDA Companion Guide R4.1 is necessary for developers of certified health IT to have appropriate implementation guidance to meet the criteria adopted in this final rule that reference USCDI v3. Based on public comments on this and prior rulemakings, we believe that the health IT industry, healthcare standards developers, and health care providers expect and support ONC making such determinations so that the adopted version of standards are the most up-to-date available and are feasible for real world implementation (see, for example, 85 FR 25677 and 25708).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters expressed concern about the deadline for this proposal and requested to extend the implementation deadline. Some suggested deadline extensions included to 24 months post-effective date of this final rule and December 31, 2025.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for expressing a desire for an extension on proposed deadlines. We have finalized a January 1, 2026 date for the expiration of the standard in § 170.205(a)(5). We believe that this deadline provides adequate time for developers and industry to support C-CDA Companion Guide R4.1, which we have finalized in § 170.205(a)(6).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A minority of commenters cautioned us about the real-world needs of physicians and patients and added complexities of implementing additional health IT standards. One commenter appreciated the flexibility and reduced burden of confirming conformance via a notification to their ONC-ACB and noted concern that certification to a new requirement may involve proof of conformance to ensure that there is clear and consistent understanding and application of requirements across developers of certified health IT.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the comments regarding the potential burden placed on providers and developers by our proposal. We do not believe that the burden on providers or developers for the adoption of a new version of the C-CDA Companion Guide is excessive. ONC has worked closely with the implementer community to help alleviate burden, and we are confident that the addition of USCDI v3 data elements will provide significant benefit.
                    </P>
                    <HD SOURCE="HD3">3. “Minimum Standards” Code Sets Updates</HD>
                    <P>We established a policy in the 2015 Edition Final Rule for minimum standards code sets that update frequently (80 FR 62612). In prior rulemaking, we discussed the benefits of adopting newer versions of minimum standards code sets, including the improved interoperability and implementation of health IT with minimal additional burden (77 FR 54170). When determining whether to propose newer versions of minimum standards code sets, we consider the impact on interoperability and whether a newer version would require substantive effort for developers of certified health IT to implement. If adopted, newer versions of minimum standards code sets would serve as the baseline for certification and developers of certified health IT would be able to use newer versions of these adopted standards on a voluntary basis. We reiterate that while minimum standard code sets update frequently, perhaps several times in a single year, these updates are confined to concepts within the code system, not substantive changes to the standards themselves. In the HTI-1 Proposed Rule, we proposed to adopt the following versions of the minimum standards code sets listed below (88 FR 23768 through 23769).</P>
                    <P>• § 170.207(a)—Problems</P>
                    <P>We proposed to remove and reserve § 170.207(a)(3), IHTSDO SNOMED CT® International Release July 2012 and US Extension to SNOMED CT® March 2012 Release. We proposed to revise § 170.207(a)(1), which is currently reserved, to reference SNOMED CT US Edition March 2022 and incorporate it by reference in § 170.299.</P>
                    <P>• § 170.207(c)—Laboratory tests</P>
                    <P>We proposed to remove and reserve § 170.207(c)(2), Logical Observation Identifiers Names and Codes (LOINC®) Database version 2.40. We proposed to revise § 170.207(c)(1), which is currently reserved, to reference LOINC Database version 2.72, February 16, 2022, and incorporate it by reference in § 170.299.</P>
                    <P>• § 170.207(d)—Medications</P>
                    <P>We proposed to revise § 170.207(d)(1), which is currently reserved, to reference RxNorm July 5, 2022, Full Monthly Release and incorporate it by reference in § 170.299. We proposed in § 170.207(d)(4) to reference the code set specified in 45 CFR 162.1002(c)(1) which includes International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM); International Classification of Diseases, 10th Revision, Procedure Coding System (ICD-10-PCS) (including The Official ICD-10-PCS Guidelines for Coding and Reporting); National Drug Codes (NDC); the combination of Health Care Financing Administration Common Procedure Coding System (HCPCS), as maintained and distributed by HHS, and Current Procedural Terminology, Fourth Edition (CPT-4), as maintained and distributed by the American Medical Association, for physician services and other healthcare services; Health Care Financing Administration Common Procedure Coding System (HCPCS) as maintained and distributed by HHS, for all other substances, equipment, supplies, or other items used in healthcare services; and Code on Dental Procedures and Nomenclature.</P>
                    <P>We have not finalized this proposal and explain the update later in this section in response to a comment in support of our proposal to update the standards for Medications in § 170.207(d).</P>
                    <P>• § 170.207(e)—Immunizations</P>
                    <P>We proposed to revise § 170.207(e)(1), which is currently reserved, to reference CVX—VaccinesAdministered, updates through June 15, 2022, and incorporate it by reference in § 170.299. We also proposed to revise § 170.207(e)(2), which is currently reserved, to reference National Drug Code Directory (NDC)—Vaccine NDC Linker, updates through July 19, 2022, and incorporate it by reference in § 170.299.</P>
                    <P>• § 170.207(f)—Race and ethnicity</P>
                    <P>We proposed to add § 170.207(f)(3) to reference CDC Race and Ethnicity Code Set Version 1.2 (July 15, 2021) and incorporate it by reference in § 170.299.</P>
                    <P>• § 170.207(m)—Numerical references</P>
                    <P>We proposed to revise § 170.207(m)(2), which is currently reserved, to reference the Unified Code for Units of Measure, Revision 2.1, November 21, 2017, and incorporate it by reference in § 170.299.</P>
                    <P>• § 170.207(n)—Sex</P>
                    <P>We proposed to revise § 170.207(n)(2), which is currently reserved, to reference the version of SNOMED CT ® U.S. Edition codes specified in § 170.207(a)(1). We also proposed to add § 170.207(n)(3) to reference the version of LOINC ® codes specified in § 170.207(c)(1).</P>
                    <P>• § 170.207(o)—Sexual orientation and gender information</P>
                    <P>
                        We proposed to change the heading of § 170.207(o) from “sexual orientation and gender identity” to “sexual orientation and gender information” to acknowledge that § 170.207(o) includes 
                        <PRTPAGE P="1225"/>
                        standard code sets to support other gender related data items. We proposed to add § 170.207(o)(3) to reference the version of SNOMED CT ® U.S. Edition codes specified in § 170.207(a)(1) and to add § 170.207(o)(4) to reference the version of LOINC ® codes specified in § 170.207(c)(1) for Pronouns.
                    </P>
                    <P>• § 170.207(p)—Social, psychological, and behavioral data</P>
                    <P>We proposed to revise § 170.207(p)(1) through (8) to reference the version of LOINC® codes specified in proposed § 170.207(c)(1) instead of § 170.207(c)(3). We proposed to revise § 170.207(p)(4), (5) and (7) and (8) to reference the version of the Unified Code of Units of Measure in proposed § 170.207(m)(2), instead of § 170.207(m)(1). We also proposed to revise § 170.207(p)(6) to include a reference to the version of the Unified Code of Units of Measure in proposed § 170.207(m)(2).</P>
                    <P>• § 170.207(r)—Provider type</P>
                    <P>We proposed to revise § 170.207(r)(2), which is currently reserved, to reference Medicare Provider and Supplier Taxonomy Crosswalk, October 29, 2021, and incorporate it by reference in § 170.299.</P>
                    <P>• § 170.207(s)—Patient insurance</P>
                    <P>We proposed to revise § 170.207(s)(2), which is currently reserved, to reference Public Health Data Standards Consortium Source of Payment Typology Code Set December 2020 Version 9.2 and incorporate it by reference in § 170.299.</P>
                    <P>
                        In addition to updating the minimum standards code sets listed above, we proposed to update some of the certification criteria that reference those minimum standards. We proposed to update some of the certification criteria that reference § 170.207(a) Problems by replacing the reference to § 170.207(a)(4) in those criteria that reference it with a reference to the new proposed § 170.207(a)(1). These criteria include § 170.315(a)(12), (b)(1)(iii)(B)(
                        <E T="03">2</E>
                        ), (b)(6)(ii)(B)(
                        <E T="03">2</E>
                        ), (c)(4)(iii)(I), and (f)(4)(ii). We also proposed to update § 170.315(f)(3)(ii) by replacing the reference to § 170.207(a)(3) with a reference to the new proposed § 170.207(a)(1).
                    </P>
                    <P>We proposed to update the certification criteria that reference § 170.207(c) Laboratory Tests by replacing the references to § 170.207(c)(2) and (c)(3) in those criteria with a reference to the new proposed § 170.207(c)(1). These criteria include § 170.315(f)(3)(ii) and (f)(4)(ii).</P>
                    <P>We proposed to update two certification criteria that reference § 170.207(e) Immunizations. We proposed to update the certification criterion § 170.315(f)(1)(i)(B), which references § 170.207(e)(3), to instead reference the new proposed § 170.207(e)(1). We also proposed to update the certification criterion § 170.315(f)(1)(i)(C), which references § 170.207(e)(4), by replacing the reference to § 170.207(e)(4) in that criterion with a reference to the new proposed § 170.207(e)(2).</P>
                    <P>
                        We proposed to update several certification criteria that reference § 170.207(f) Race and Ethnicity. We proposed to update certification criteria that reference § 170.207(f)(2) to instead reference the new proposed § 170.207(f)(3). These criteria include § 170.315(a)(5)(i)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ) and § 170.315(c)(4)(iii)(H).
                    </P>
                    <P>
                        As described in sections III.C.1 and III.C.8 of this final rule, we proposed to update criteria that reference § 170.207(n) Sex by updating criteria that reference § 170.207(n)(1) to reference the new proposed § 170.207(n)(2). More specifically, we proposed to update § 170.315(a)(5)(i)(C) to reference § 170.207(n)(1) for the time period up to and including December 31, 2025, or to reference § 170.207(n)(2). We also proposed to update § 170.315(c)(4)(iii)(G) and § 170.315(b)(1)(iii)(G)(
                        <E T="03">3</E>
                        ) to reference § 170.207(n)(2). We note 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). ONC has finalized § 170.315(b)(1)(iii)(G)(
                        <E T="03">3</E>
                        ) without the proposed reference to § 170.213. We have 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. Health IT developers may update to a newer version if one exists at effective date of the criterion.
                    </P>
                    <P>Additionally, as described in sections III.C.1 and III.C.8 of this final rule, we proposed to update the criteria that reference § 170.207(o) Sexual orientation and gender information (as we proposed to rename the criterion) by updating criteria that reference § 170.207(o)(1) and (2). We proposed to replace the reference to § 170.207(o)(1) in § 170.315(a)(5)(i)(D) with a reference to the new proposed § 170.207(o)(3) and proposed to replace the reference to § 170.207(o)(2) in § 170.315(a)(5)(i)(E) with a reference to the new proposed § 170.207(o)(3). More specifically, we proposed to update § 170.315(a)(5)(i)(D) to reference § 170.207(o)(1) for the time period up to and including December 31, 2025, or to reference § 170.207(o)(3), as well as whether a patient declines to specify sexual orientation. We proposed to update § 170.315(a)(5)(i)(E) to reference § 170.207(o)(2) for the time period up to and including December 31, 2025, or to reference § 170.207(o)(3), as well as whether a patient declines to specify gender identity.</P>
                    <P>We also proposed to update § 170.315(c)(4)(iii)(C), which references § 170.207(r) Provider Type. Specifically, we proposed to replace the reference to § 170.207(r)(1) in that criterion with a reference to the new proposed § 170.207(r)(2). We also proposed to update § 170.315(c)(4)(iii)(E), which references § 170.207(s) Patient insurance. Specifically, we proposed to replace the reference to § 170.207(s)(1) in that criterion with a reference to the new proposed § 170.207(s)(2).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Most commenters were supportive of ONC's proposal to adopt updated minimum code set versions. Meanwhile other commenters had recommendations pertinent to specific standards considered a “minimum standard” code set.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support of our proposal to adopt updated minimum code set versions. We have finalized the adoption of updated minimum standard code set versions as proposed. We note that newer versions of the codes sets may have become available since we published the HTI-1 Proposed Rule and this does not preclude developers of certified health IT from updating minimum code sets to newer versions in their Health IT Modules.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters suggested different naming conventions for different standards and data concepts included as part of the Program's minimum standard code sets, including the name of Patient Demographics, Sexual Orientation, and Gender Identity.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments. However, we have finalized the title of § 170.207(o) to reflect the inclusion of the minimum standard code set for Pronouns in that section, and we have finalized our proposal to update the Sexual Orientation and Gender Identity title in § 170.207(o) to “Sexual orientation and gender information” to provide clarity on the standard code sets related to data elements in that section. We have also finalized our proposal to update the “demographics” title in § 170.315(a)(5) to “patient demographics and observations” to acknowledge that not all data described in that section are understood to be demographics.
                        <PRTPAGE P="1226"/>
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received multiple comments encouraging ONC to continue to work with the HL7 Gender Harmony project team and federal partners to update terminology definitions over time.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support of our working with the HL7 Gender Harmony project team and federal partners to update terminology definitions. We anticipate ongoing collaboration with these parties to promote collection and exchange of data elements related to health equity and support for underserved populations.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a comment in support of the proposal to update the standards for Medications at § 170.207(d); however, the commenter noted that the reference to 45 CFR 162.1002(c)(1) for NDC includes references to medical code sets that are not appropriate for medications and the reference should be changed to 162.1002(b)(2), which is specific to NDC.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for their support of our proposed updates. We note that our reference to 45 CFR 162.1002(c)(1) in the proposal was intended to be consistent with the timeframes identified in the referenced regulation—
                        <E T="03">i.e.,</E>
                         “For the period on and after October 1, 2015” as opposed to 45 CFR 162.1002(b)(2) which is referenced as “For the period on and after October 16, 2003 through September 30, 2015.” However, we agree with the commenter that the reference should include only NDC, and we have finalized § 170.207(d)(4) to reference 45 CFR 162.1002(b)(2) as referenced in 45 CFR 162.1002(c)(1) for the period on and after October 1, 2015.” We did not intend to cross-reference code sets no longer in effect, and we believe that commenters would have anticipated us to correct this.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments related to the OMB Initial Proposals For Updating OMB's Race and Ethnicity Statistical Standards and the 2022 proposed updates to the CDC Race and Ethnicity code set. Some commenters suggest that ONC prioritize and prepare for any changes that may be necessary should the proposed changes be finalized. Other commenters expressed concern that the proposed changes will have a significant impact on health IT. Some commenters provided suggestions for ONC to develop data collection guidelines and provided suggestions for code set content updates.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input regarding the proposed updates to the CDC race and ethnicity code set and OMB race and ethnicity collection; however, these comments are out of scope for this rulemaking. We will continue to work with federal partners to promote alignment for these data concepts.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments regarding the effective dates for the new minimum code set versions. Some comments suggested that ONC specify the time health IT developers must incorporate the new code set versions once they have been published to allow time for health IT developers and providers to incorporate the new versions. Other commenters recommended that ONC align code set version update timelines to the base program requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input regarding the effective dates for new minimum code set version and to align code set version updates timelines to the base Program requirements. We have finalized the adoption of § 170.207 with a compliance date of January 1, 2026.
                    </P>
                    <P>We have adopted the proposed version of code sets. Again, we note that we have adopted minimum code set versions and this does not preclude developers of certified health IT from updating minimum code sets to newer versions in their Health IT Modules.</P>
                    <HD SOURCE="HD3">4. Electronic Case Reporting</HD>
                    <P>As discussed in the HTI-1 Proposed Rule, case reporting serves as early notification to Public Health Agencies (PHAs) for potential disease outbreaks and includes information that enables PHAs to start contact tracing and other prevention measures. (88 FR 23769)</P>
                    <P>
                        Since ONC adopted 45 CFR 170.315(f)(5) as a functional requirement for Health IT Modules in the 2015 Edition, standards development organizations (SDOs), public health, and interested parties within the healthcare industry have balloted several standards related to electronic case reporting. The standards were produced and developed through a collaborative effort among many partners, including CDC, the Council of State and Territorial Epidemiologists (CSTE), the Association of State and Territorial Health Officials (ASTHO), the Association of Public Health Laboratories (APHL), EHR developers, and the HL7 Public Health (PH) Work Group.
                        <SU>46</SU>
                        <FTREF/>
                         These standards pertain to both HL7® FHIR and HL7® CDA and include multiple Implementation Guides (IGs).
                    </P>
                    <FTNT>
                        <P>
                            <SU>46</SU>
                             See work group membership at: 
                            <E T="03">https://confluence.hl7.org/display/PHWG/Public+Health+Work+Group.</E>
                        </P>
                    </FTNT>
                    <P>Recognizing advancement of standards development in this area, ONC analyzed the currently balloted standards for potential inclusion in the existing 45 CFR 170.315(f)(5) criterion. As discussed in detail in the HTI-1 Proposed Rule, ONC examined the standards for potential inclusion as a part of this criterion (88 FR 23770-23771).</P>
                    <P>In the HTI-1 Proposed Rule (88 FR 23771-23772), we proposed to adopt standards for electronic case reporting in § 170.315(f)(5)(ii). This included a proposal in § 170.315(f)(5)(ii)(A) that a Health IT Module certified to § 170.315(f)(5) support the consumption and processing of electronic case report trigger codes and parameters based on a match from Reportable Conditions Trigger Code value set in § 170.205(t)(4) received from the eRSD profiles as specified in the HL7 FHIR eCR IG in § 170.205(t)(1). We clarified that a Health IT Module need only support parsing and consuming the eRSD Specification Library and eRSD Supplemental Library because we understand that health IT developers may choose to either manually encode the electronic case reporting trigger logic into Health IT Modules or may support a more automated process for encoding the trigger logic into Health IT Modules. We requested comment on this approach and on whether there is general support of the eRSD Specification Library and eRSD Supplemental Library for electronic case reporting triggering (88 FR 23773).</P>
                    <P>Additionally, we proposed in § 170.315(f)(5)(ii)(B) to require a Health IT Module to create a case report for electronic transmission according to at least one of the following two HL7® standards: in accordance with the electronic initial case report (eICR) profiles specified in the HL7 FHIR eCR IG in § 170.205(t)(1) or in accordance with the HL7 CDA eICR IG in § 170.205(t)(2). Finally, we proposed in § 170.315(f)(5)(ii)(C) to require that Health IT Modules certified to § 170.315(f)(5) support the receipt, consumption, and processing of reportability responses (RR) formatted according to the RR profiles defined in the HL7 FHIR eCR IG or the HL7 CDA RR IG.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received numerous comments and broad support for updating the “electronic case reporting” criterion to reference standards-based requirements. Commenters stated that the current functional certification criteria in the Program do not meet eCR program needs and that requiring use of a standard would improve interoperability and implementation 
                        <PRTPAGE P="1227"/>
                        consistency to further enable the transmission of timely, granular, and accurate case data between health providers and public health agencies. Commenters stated that moving from functional electronic case reporting requirements to standards-based requirements is an important step toward ensuring that public health programs have access to critical data. Commenters also stated there is substantial opportunity to empower public health, improve public health surveillance, and more efficiently monitor and manage public health concerns through standardization of electronic case reporting. Others wrote that the standards would improve consistency and increase real-time communication between healthcare and public health.
                    </P>
                    <P>Several commenters supported the requirements as proposed, including the requirements for Health IT Modules to support either HL7 FHIR or HL7 CDA standards for case reporting. Some commenters stated the need for EHRs to support the HL7 CDA standard since many public health agencies only accept HL7 CDA documents. Several commenters stated that both the HL7 CDA and the HL7 FHIR standards should be required to allow Public Health Agencies (PHAs) time and the appropriate resources to be able to receive incoming electronic case reports. Other commenters stated they would prefer a single standard be included in the criterion rather than including multiple options for certification. Commenters noted that existing health information conversion tools could help with the translation between HL7 CDA and HL7 FHIR formats. Additionally, commenters advocated that the electronic case report and the reportability response should adhere to the same standard (CDA or FHIR) and noted that it would be burdensome if the reportability response from public health was based on a different standard than the initial case report.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments and agree with the importance of including standards to improve interoperability and public health agencies' access to critical information. Taking into consideration feedback from commenters, we have finalized our proposal in § 170.315(f)(5)(ii)(B) to require Health IT Modules to enable a user to create a case report consistent with at least the eICR profile of the HL7 FHIR eCR IG in § 170.205(t)(1) or the HL7 CDA eICR IG § 170.205(t)(2). Additionally, we have finalized in § 170.315(f)(5)(ii)(C) to require Health IT Modules to receive, consume, and process a case report response according to the reportability response profile of the HL7 FHIR eCR IG in § 170.205(t)(1) or the HL7 CDA RR IG in § 170.205(t)(3) as determined by the standard used in (f)(5)(ii)(B) of this section. We have finalized this requirement to ensure that a Health IT Module that creates a case report according to the eICR profile of HL7 FHIR eCR IG can receive, consume, and process a case report response using the same HL7 FHIR eCR IG. The same would be true for a Health IT Module that creates a case report according to the HL7 CDA eICR IG; this Health IT Module must be capable of receiving a reportability response according the HL7 CDA RR IG. We believe requiring support for creating a case report based on either the HL7 FHIR eCR IG or the HL7 CDA eICR IG while requiring support for receipt, consumption, and processing of a case report response according to either the HL7 FHIR eCR IG or the HL7 CDA RR IG provides technical design flexibility while supporting the HL7 CDA-based landscape for case reporting that exists today. Additionally, we have finalized our proposal in § 170.315(f)(5)(ii)(D) for Health IT Modules to support transmission of a case report electronically to a system capable of receiving a case report.
                    </P>
                    <P>As with most consensus-based standards, we recognize that additional improvements can be made to the HL7 FHIR and HL7 CDA IGs for case reporting. We encourage interested parties, including the CDC, the appropriate HL7 working groups, and public health associations to update and improve the IGs, as well as collaborate on solutions that facilitate the ability of PHAs to parse, filter, and consume case reports. We plan to continue monitoring the development of standards for case reporting and foundational standards that facilitate interoperability for various public health use cases. As the HL7 FHIR-based certification criteria in the Program continue to grow and industry more broadly supports HL7 FHIR-based IGs, we intend to transition to solely an HL7 FHIR-based approach for case reporting in future rulemaking.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested that the adoption of HL7® standards was unnecessary to advance interoperability for EHI because EHR systems are capable of effectively and securely communicating using multiple standards and messaging formats. This commenter stated that the adoption of HL7 standards would prevent health care providers from using other standards that could better serve different situations and communities.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We disagree that adoption of standards for case reporting is unnecessary to advance interoperability. We note that for nearly a decade, Program requirements for electronic case reporting have not been standards-based, and numerous examples cited in this preamble and in the HTI-1 Proposed Rule reveal deficiencies in nationwide electronic case reporting due to misaligned technical standards and implementations. We believe that consensus has emerged for adoption of HL7 standards, which we have finalized in § 170.315(f)(5)(ii), and we believe that such standards can be enhanced over time to address the emergent needs of health care providers and the communities they serve.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received multiple comments supporting our proposal relating to the consumption and processing of case report trigger codes based on the Reportable Conditions Trigger Code value set in § 170.205(t)(4). Many public health agency commenters expressed support to require certified Health IT Modules to support the ability to consume and process the eRSD profiles, which include the RCTC value set, regardless of whether such a Health IT Module supports a FHIR-based or CDA-based approach to certification, stating that it would support interoperability. One hospital-based commenter suggested that in addition to the mandated proposed RCTC value sets, ONC should require support for the adjunct `eRSD Supplemental Library' as part of the certification criterion at § 170.315(f)(5) as we proposed. Several health IT developer commenters stated that the eRSD profiles should not be required, including the reference to the eRSD Supplemental Library or the eRSD Specification Library, stating that the underlying standards are too immature and not sufficient for broad use. Commenters further stated concerns about the burdensome and manual updates and maintenance required to support the eRSD profiles and noted that the specification is mainly in use today by the eCR Now FHIR App, a solution developed specifically for case reporting. One commenter suggested that Health IT Modules should be required to use updated reportable condition trigger codes, stating that during an emergency, new trigger codes are almost always needed and are necessary in effectiveness of use in an emergency response. One commenter emphasized coordination with the CDC to not only make eRSD-based sharing of reportable events available, but also the Reportable Conditions Knowledge Management System (RCKMS) to enable 
                        <PRTPAGE P="1228"/>
                        efficient sharing of PHA requirements in terms of reportable events, content, format, and transport.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their perspectives. We agree that consuming and processing reportable condition trigger codes is a necessary first step in electronic case reporting, and we have finalized in § 170.315(f)(5)(ii)(A) our proposal that Health IT Modules certified to § 170.315(f)(5) must, beginning January 1, 2026, support the consumption and processing of case reporting trigger codes and must identify a reportable patient visit or encounter based on a match from the RCTC value set in § 170.2015(t)(4). However, after additional examination of the HL7 FHIR eCR specification, and in response to comments received, we have not adopted our proposal to require that such Health IT Modules receive the RCTC value set from the eRSD profiles as specified in the HL7 FHIR eCR IG in § 170.205(t)(1). This means that Health IT Modules do not need to support the eRSD profiles, including the eRSD PlanDefinition, Supplemental Library, and Specification Library, in order to be certified to § 170.315(f)(5).
                    </P>
                    <P>We have finalized this approach to allow developers of certified health IT flexibility to support the consumption of the RCTC value set in the way that best suits their technology and in a way that does not constrain how the RCTC value set is consumed as the underlying standards mature. We share concerns with commenters who noted that the triggering logic within the eRSD profiles of the FHIR IG are complex, not supported across the industry, and remain largely untested outside their use in the eCR Now FHIR App. We believe requiring that a Health IT Module certified to § 170.315(f)(5) support the consumption and processing of case reporting trigger codes and identify a reportable patient visit or encounter based on a match from the RCTC value set in § 170.205(t)(4), without further constraining how the RCTC value set is received, will simplify Program conformance and responds to concerns raised by commenters and raised through our own analysis.</P>
                    <P>
                        For purposes of Program conformance, we reiterate from the HTI-1 Proposed Rule that the RCTC value set in § 170.205(t)(4) is a minimum standard code set, and that Health IT Modules certifying to § 170.315(f)(5) by way of § 170.315(f)(5)(ii) may voluntarily support an updated version (
                        <E T="03">e.g.,</E>
                         a subsequent release) of the RCTC value set. We anticipate that health IT developers would be incentivized by their customers to take advantage of this opportunity to voluntarily support updated versions of the RCTC value set because updated versions will likely include new codes reflecting new or emerging infectious diseases (88 FR 23773). We urge developers with Health IT Modules certified to § 170.315(f)(5)(ii) to support all the reportable condition trigger codes in the RCTC value set as it updates so that emerging infectious diseases may be reported electronically to public health authorities as those infectious diseases emerge.
                    </P>
                    <P>
                        We note that the RCTC value set is not currently hosted on the National Library of Medicine Value Set Authority Center, like many other value sets. Instead, the RCTC value set is currently available for distribution by the Association of Public Health Laboratories.
                        <SU>47</SU>
                        <FTREF/>
                         We plan to work with CDC and the industry to align the availability of the RCTC value set with other, similar value sets in the future.
                    </P>
                    <FTNT>
                        <P>
                            <SU>47</SU>
                             Electronic Reporting and Surveillance Distribution page managed by the Association of Public Health Laboratories: 
                            <E T="03">https://ersd.aimsplatform.org/#/home</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        Finally, we note that the CDA IG cross-references the RCTC value set specified in the HL7 FHIR eCR IG.
                        <SU>48</SU>
                        <FTREF/>
                         Therefore, Health IT Modules certified to § 170.315(f)(5) using the HL7 CDA IG as described in § 170.315(f)(5)(i), must also support the requirement to trigger a case report based on a match from the RCTC value set in § 170.205(t)(4) at a minimum. We encourage implementers to reference the HL7 CDA eICR IG for additional guidance regarding the use of the RCTC value set for identifying reportable cases.
                    </P>
                    <FTNT>
                        <P>
                            <SU>48</SU>
                             See section 1.11.2 of the CDA eICR IG titled, “Using the eRSD (from the FHIR eCR IG).” 
                            <E T="03">https://www.hl7.org/implement/standards/product_brief.cfm?product_id=436.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters suggested requiring a longer compliance date than December 31, 2024, for health IT developers to certify to the proposed updated criterion to allow the industry to widely implement the standards-based requirements in production. One commenter expressed support, stating that allowing current standards requirements to remain until December 31, 2024, is reasonable, while another commenter recommended an implementation deadline of December 31, 2025. Several commenters stated that more time should be given for compliance, such as a minimum of 24 months post-final rule effective date for such deadlines or postponing the requirement for electronic case reporting until public health jurisdictions can adequately adapt to the technology needed to ingest the data. One commenter expressed that more time is needed to develop, test, and deliver new capabilities, stating that the proposed timeframe is insufficient.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' concerns about the timelines for conformance to new standards for the Program. We have finalized in § 170.315(f)(5) that Health IT Modules must enable a user to create a case report for electronic transmission meeting requirements in § 170.315(f)(5)(i) for the time period up to and including December 31, 2025, or meet the requirements in § 170.315(f)(5)(ii). This approach will allow developers to continue to certify to functional requirements for case reporting according to § 170.315(f)(5)(i) while allowing developers to certify to the standards-based approach to case reporting in § 170.315(f)(5)(ii). After December 31, 2025, developers will only be able to certify to case reporting using the standards-based approach described § 170.315(f)(5)(ii). In addition, previously certified products will need to update their certification to the standards-based approach described in § 170.315(f)(5)(ii) by December 31, 2025. We believe this date will provide adequate time for developers of certified health IT with Health IT Modules certified to § 170.315(f)(5) to comply with the requirements we have finalized, while also ensuring timely implementation of the requirements for public health agencies.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters suggested that systems receiving electronic case reports should also have to certify to capabilities that align with the requirements in § 170.315(f)(5). Another commenter stated that there is little value in requiring the capability to transmit electronic case reporting if public health partners do not have the capabilities to receive data electronically. Some commenters stated that they are prepared to support electronic case reporting but have not been able to do so due to lack of public health capacity to receive it, and recommended ONC work with other agencies to support public health partners with funding to bolster electronic case reporting capacity. Several commenters suggested ONC provide support for the transition to eCR reporting, such as ONC collaborating with other agencies and public health entities to provide financial resources/incentives and support, as well as publishing and maintaining a master list of U.S. public health data standards, and work with state and local public health agencies to ensure technical readiness for their adoption and implementation. One commenter 
                        <PRTPAGE P="1229"/>
                        recommended ONC encourage and enforce public health agencies to move away from manual reporting. The same commenter also urged coordination to promote the reduction and elimination of variances in format and transport mechanisms.
                    </P>
                    <P>One commenter expressed support and requested clarification if the intent is to require support based on the standards ONC specifies, and not to require support for jurisdiction-specific communication methods. Another commenter stated that state and local variations create burden on the sender to meet specific requests and needs of jurisdictions. One commenter requested further guidance through a companion guide on how to comply with differing federal and state regulations related to electronic case reporting requirements, such as what additional data elements are needed by state PHAs and beyond those that are defined in the standards. Multiple commenters expressed concern regarding variability in implementation of standards, and the jurisdictional distinctions that required customizations and manual burden to maintain. We received a few comments stating that the proposed requirements are too broad and urged a more tempered approach to permit maturation as integrations increase. One commenter stated that the proposal does not describe likely performance parameters or offer an architecture that would support true disease surveillance. Some commenters expressed concern with public health agencies' lack of readiness for electronic case reporting, stating that, in their experience, production use of electronic case reporting is limited for conditions beyond COVID-19 and Mpox.</P>
                    <P>
                        <E T="03">Response.</E>
                         We understand that gaps remain in practice regarding the ability of public health agencies to receive electronic case reports, particularly with parsing, filtering, and consuming incoming electronic case reports, and that manual reporting mechanisms remain in place for many reportable conditions. We appreciate the commenters that suggested we create an aligned requirement for systems receiving electronic case reports and will consider these comments for future rulemaking. We are supportive of CDC-led efforts to build public health capacity to accept electronic case report information, and the electronic receipt and ingestion of electronic case reports are a core component of the CDC Public Health Data Strategy.
                        <SU>49</SU>
                        <FTREF/>
                         We believe the timeline for requiring standards-based electronic case reporting for Health IT Modules certified to § 170.315(f)(5) will allow both healthcare organizations and public health agencies to develop and implement the capability for receipt and exchange of electronic case reports and associated information. We recognize the need for ONC to continue to collaborate and coordinate with CDC and national public health associations, as well as with public health jurisdictions. Further, there are tools and intermediary options available, like HL7 CDA to HL7 FHIR conversion tools, that PHAs could leverage to accept incoming HL7 FHIR-based case reports and convert them into a format they can receive and process.
                    </P>
                    <FTNT>
                        <P>
                            <SU>49</SU>
                             
                            <E T="03">https://www.cdc.gov/ophdst/public-health-data-strategy/Public_Health_Data_Strategy-final-P.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>We acknowledge that variations between state and federal requirements and local requirements and needs add burden for reporters. However, we are unable to holistically solve this challenge through the Program. The Program is voluntary, and developers that elect to participate are only required to adhere to the requirements in applicable certification criteria. The Program does not directly address case reporting requirements imposed by state or local bodies. Furthermore, we believe these issues could be addressed through the standards development processes, including through the Public Health Workgroup for HL7, and through working with PHAs and appropriate public health associations to align on the use of a national standard and reduce state and local variation in requirements where possible. Regarding comments that the proposals are too broad, we believe requiring standards-based support for electronically reporting case reports and receiving reportability responses, including using standard triggers, will allow for implementation flexibility while improving interoperability. Further, standards-based requirements can help to reduce variation and fragmentation that may otherwise cause interoperability issues for implementers and users. We understand that PHAs expressed concerns related to technology used by PHAs being able to accept incoming reports that adhere to the FHIR standard. We believe that the longer timeline can help with this transition, as well as allow the industry time to pursue different approaches to implementing the required components of the eCR FHIR IG. We understand concerns related to performance, scalability, and maintenance, and will monitor standards development and implementation to inform future rulemaking.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters stated that public health-specific approaches for data exchange should not be the way of the future, and that existing solutions, such as FHIR capabilities including subscriptions and patient-level queries, should instead be leveraged for the purposes of public health data exchange. Several commenters believe common data infrastructure and standards, such as HL7 FHIR-based APIs and the SMART Backend Services, would better serve electronic case reporting than the current standards, which they stated are brittle and require consistent updating and manual support. Several commenters offered suggestions of additional functionality. One commenter suggested that health IT developers must provide functionality to users to send on-discharge summary updates for patients admitted to hospital, and interfaces to allow their users to adjust timing of triggering, document build, send, and other parameters. One commenter suggested that ONC incorporate the language and data elements of specialty records into its standards to increase effectiveness for interoperability initiatives across the spectrum of patient care. Another commenter suggested requiring functionality related to high-risk and immediate reporting for provider-initiated (or `manually triggered') electronic reporting stating that provider-triggered `manual' eCRs are critical for emergency preparedness and reducing the burden on healthcare staff and public health staff of manual reporting and data entry in future outbreaks, novel conditions, and early in confirmed outbreak scenarios. One commenter stated that healthcare facility IDs and address formatting cause serious impacts for public health because they cannot be verified for eCRs sent. The commenter, therefore, suggested more standards conformance and health IT functionality to allow users to easily edit, update, and maintain correct facility IDs, as well as consistent formatting of address and rational facility naming, will ease processing burden on PHAs and other data receivers. Several comments mentioned specific challenges within the proposed specifications, including challenges with certain data elements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We acknowledge the importance of reusable and scalable standards for health information interoperability including standards-based APIs. The Standardized API for “patient and population services” criterion at § 170.315(g)(10) has provided a baseline for reusable services to advance interoperability nationwide. 
                        <PRTPAGE P="1230"/>
                        Like many other HL7 FHIR IGs in the US Realm, the HL7 FHIR profiles defined in the eCR FHIR IG were built using the profiles defined in the US Core IG as part of the HL7 FHIR profiling model.
                        <SU>50</SU>
                        <FTREF/>
                         Notably, the US Core IG is part of the certification criterion at § 170.315(g)(10), adopted in § 170.215(b)(1) and incorporated by reference in § 170.299. While we recognize the potential of these foundational APIs, implementation guides, and services to generally support public health, we believe it is helpful to provide further specificity for use cases like electronic case reporting. We will consider ways to align the public health certification criteria in the Program to promote reuse of common standards to support various public health reporting and interoperability use cases in future rulemaking. We appreciate that challenges and additional potential uses and applications of the electronic case reporting standard remain. However, the Program is not the venue through which the specification can be updated or changed. We encourage commenters to participate in standards development processes, including in the HL7 Public Health Workgroup. Further, we are aware that tools exist for PHAs that can translate incoming FHIR to CDA and/or other formats that public health surveillance systems can currently accept, which can aid with data receipt in the interim period as surveillance systems are updated to be able to receive FHIR and as additional FHIR-based tools and solutions are developed and implemented.
                    </P>
                    <FTNT>
                        <P>
                            <SU>50</SU>
                             
                            <E T="03">https://hl7.org/fhir/R4/profiling.html#reslicing</E>
                            .
                        </P>
                    </FTNT>
                    <P>For concerns related to triggering and adjusting triggers based on timing and the occurrence of certain events, we believe this can be addressed through healthcare organizations and other reporters working with public health jurisdictions to determine the timing and triggers that work for all involved participants and that do not place undue burden on health IT and public health systems. We also encourage triggering and timing approaches to be discussed through standards development processes to develop, pilot, and share approaches that meet the needs of both reporters and public health agencies.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested clarification on whether the Health IT Module being certified needs to identify any intermediaries involved in the transmission of electronic case reports or RR messages as part of certification, or if these intermediaries need to also be certified for these eCR criteria. Another commenter requested clarification on how a “system capable of receiving an electronic case report” would be identified or validated, and whether this system would need to be certified against specific criteria. A few commenters recommended recognition, or new certification processes using the eCR Now FHIR application with a companion guide, as well as a different set of data than the USCDI v1 data set cited as standard for the criterion to ensure health IT systems can meet the new certification criteria. One commenter suggested that the eCR Now FHIR App should be accepted for certification. Some commenters expressed a belief that continued success in case reporting relies on a reasonable expectation of a routing and decision support intermediary such as AIMS (APHL Informatics Messaging Services). One commenter suggested that the AIMS network should support the submission (and response to submission) of any public health reporting using RESTful (or Representational State Transfer) application programming interfaces. One commenter recommended that ONC work closely with the CDC and the AIMS Platform team to ensure requirements do not exceed or violate the AIMS requirements, stating that many of the proposals are beyond the current allowed features on the AIMS network application programming interfaces. One commenter recommended that ONC work closely with the CDC and the AIMS Platform team to ensure requirements do not exceed or violate the AIMS requirements, stating that many of the proposals are beyond the current allowed features on the AIMS network.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the questions we received related to intermediaries, the use of specific tools or systems, and the applicability of the Program to intermediaries. Our Program is voluntary, and health IT developer participation in the Program has traditionally been incentivized through connections to CMS payment programs. While we do not have the authority to enforce or provide incentives for adoption of certified Health IT Modules, other entities could choose to do so. Should other federal entities choose to require certain systems or technologies to certify to the criterion at § 170.315(f)(5) via other mechanisms, the applicability of the requirements could extend beyond health IT that is traditionally presented for certification. Additionally, developers of intermediary software may also voluntarily certify their technology through the Program without incentives or requirements.
                    </P>
                    <P>
                        As part of the Program, we do not require the use of specific systems or solutions, such as the eCR Now FHIR App, which several commenters raised. Rather, we specify standards-based requirements based on standards and implementation specifications that have been developed through consensus by the health IT industry and functional requirements to allow for flexibility and innovation. We are aware that the eCR Now FHIR App is an option for transmitting electronic case reports using either the HL7 CDA IG or the HL7 FHIR eCR IG. We also are aware of the CDC-supported data ingestion building blocks that can aid PHAs in converting incoming information from HL7 FHIR to HL7 CDA so that surveillance systems are able to process reports in the standards with which they can currently receive data. Developers of certified health IT have the flexibility to leverage the eCR Now FHIR App or other solutions to meet the requirements under our Program under existing requirements for § 170.315(f)(5). Further, as developers of certified health IT work to implement either the CDA or FHIR standards as part of their Health IT Modules, they can use “relied upon software” to demonstrate certification criteria compliance (see 84 FR 7433 and 76 FR 1276-1277).
                        <SU>51</SU>
                        <FTREF/>
                         This encompasses third-party software or products that are not developed by the health IT developer but are being used to meet a portion of (or the entirety of) certain certification criteria. Such third-party products must be reported to the Certified Health IT Product List. We are aware that there are several technical options that meet our required functional criteria adhering to the FHIR standard. Intermediaries, such as the AIMS platform supported by APHL, as well as other intermediaries such as HIEs or HINs, are used by healthcare organizations to assist with routing, transport, and, in some cases, conversion before submitting electronic case reports to PHAs. However, we do not dictate the mechanism through which vendors or organizations choose to accomplish the electronic case reporting workflow—only the functional expectations and the accompanying standard(s). At this time, ONC is not requiring Health IT Modules certified to § 170.315(f)(5) to specifically connect to AIMS or support RCKMS 
                        <SU>52</SU>
                        <FTREF/>
                         to meet the proposed requirements in § 170.315(f)(5)(ii)(D). While we 
                        <PRTPAGE P="1231"/>
                        understand the role AIMS and RCKMS play in a centralized, hub-and-spoke model for electronic case reporting, we proposed that the functional requirements for § 170.315(f)(5)(ii)(D) remain agnostic as to which reporting platform and which decision support tool(s) are used. Further, the use of HL7 FHIR supports the use of RESTful APIs. We will continue to coordinate and work with CDC on ensuring support is available as Health IT Modules work toward Certification of the “electronic case reporting” criterion, regardless of their approach. Given public comments and our desire to support providers reporting electronic case reports to any PHA that may be authorized to receive case reports, we have finalized our requirements in § 170.315(f)(5)(ii)(D) to “transmit a case report electronically to a system capable of receiving an electronic case report,” as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>51</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/relieduponsoftwareguidance.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>52</SU>
                             
                            <E T="03">https://www.rckms.org/.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended that systems be tested with “live” public health information systems, or systems specified by the public health community instead of self-certifying that real world testing has been completed. The same commenter also recommended that if a Health IT Module is certified only for CDA or FHIR exchange of RR data, the Health IT Module must also successfully complete real world testing with a commercially available service to transform the data into the format not implemented as part of the Health IT Module to ensure the provider can receive RR messages regardless of the format utilized. One commenter recommended that timely and or automated eRSD updates should be considered for inclusion in real world testing. One commenter expressed that they appreciate the requirement to ensure Health IT Modules continue to demonstrate conformance through real world testing.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments and note that electronic case reporting is subject to the Real World Testing Condition and Maintenance of Certification requirements at § 170.405(a). However, we note that developers of certified Health IT Modules subject to real world testing have extensive flexibility to design real world testing approaches that meet requirements established in § 170.405(b)(1)(iii). We decline to establish specific requirements for real world testing plans beyond what is established in § 170.405(b)(1)(iii) for electronic case reporting currently. We also note that our requirement for Health IT Modules certifying to § 170.315(f)(5)(ii) to use either the FHIR-based or CDA-based IG is intended to facilitate interoperability and should not necessitate support for multiple formats to receive RR messages. Several commenters were concerned about receiving RRs in a different standard than the sent eICR, and we encourage the reporters to work with PHAs and intermediaries to limit the potential differentiation in standards used for eICR and RR, and to consider the use of potential solutions that could convert the eICR or RR into the corresponding standard.
                    </P>
                    <P>
                        We have finalized the revised criterion for electronic case reporting in § 170.315(f)(5) with modifications. First, we have finalized a modification of the proposed description in § 170.315(f)(5) from “an electronic case report” to “a case report for electronic transmission” consistent with the prior functional criterion in § 170.315(f)(5). Second, we have modified the date from December 31, 2024 to December 31, 2025 for certification to the existing functional criterion, which is now specified in § 170.315(f)(5)(i) 
                        <E T="03">Functional electronic case reporting.</E>
                         For the standards-based version of the criterion in § 170.315(f)(5) and specified in § 170.315(f)(5)(ii) 
                        <E T="03">Standards-based electronic case reporting,</E>
                         we have finalized a modification to the proposed regulation text to reference the Reportable Conditions Trigger Code value set in § 170.205(t)(4) without including the reference to the HL7 FHIR eCR IG in § 170.315(f)(5)(ii)(A). We have finalized a modification to the proposed regulation text as described above to reference only the HL7® CDA® eICR IG in § 170.315(f)(5)(ii)(B)(2). We have finalized a modification to the proposed regulation text for the capabilities described in § 170.315(f)(5)(ii)(C) by adding “as determined by the standard used in (f)(5)(ii)(B) of this section.” Finally, we have finalized a modification to § 170.315(f)(5)(ii)(D) to modify “capable of receiving an electronic case report” as follows: “Transmit a case report electronically to a system capable of receiving a case report.”
                    </P>
                    <HD SOURCE="HD3">5. Decision Support Interventions and Predictive Models</HD>
                    <P>
                        Since 2010, the Program has maintained a CDS certification criterion, consistent with the 
                        <E T="03">qualified electronic health record</E>
                         definition in section 3000(13) of the PHSA, which defines a qualified EHR as an electronic record of health-related information on an individual that has the capacity to “provide clinical decision support” (42 U.S.C. 300jj(13)(B)(i)). The initial requirements for the CDS certification criterion were intended to ensure that Health IT Modules would support broad categories of CDS while being agnostic toward the intended use of the CDS beyond drug-drug and drug-allergy interaction checks (75 FR 2046).
                    </P>
                    <P>
                        In 2012, ONC established a new set of requirements for Health IT Modules to support CDS. These requirements included capabilities to support evidence-based CDS based on a defined set of data elements; CDS configuration for both inpatient and ambulatory settings; and the display of source attribute or bibliographic citation of CDS (77 FR 54212). These requirements were largely based on recommendations made by ONC's Health Information Technology Policy Committee (HITPC) 
                        <SU>53</SU>
                        <FTREF/>
                         from 2011 recommending ONC require Health IT Modules support CDS, including: (1) display source or citation of CDS; (2) be configurable based on patient context (
                        <E T="03">e.g.,</E>
                         inpatient, outpatient, problems, meds, allergies, lab results); (3) be presented at a relevant point in clinical workflow; (4) include alerts presented to users who can act on alerts (
                        <E T="03">e.g.,</E>
                         licensed professionals); and (5) be integrated with the EHR (
                        <E T="03">i.e.,</E>
                         not standalone). In the 2015 Edition Final Rule, ONC finalized an updated CDS criterion in § 170.315(a)(9) (80 FR 62622).
                    </P>
                    <FTNT>
                        <P>
                            <SU>53</SU>
                             Health Informational Technology Policy Committee (HITPC) Transmittal Letter to the National Coordinator. June 2011. 
                            <E T="03">https://www.healthit.gov/sites/default/files/facas/hitpc-stage-2-mu-recommendations.pdf#page=4.</E>
                        </P>
                    </FTNT>
                    <P>
                        Since the CDS criterion was first adopted in § 170.315(a)(9), health IT implementation and technology resources used to support clinical decision-making have continued to evolve and expand across the health IT ecosystem. Within healthcare today, predictive models are increasingly being used and relied upon to inform an array of decision-makers, including clinicians, payers, researchers, and individuals, and to aid decision-making through CDS.
                        <SU>54</SU>
                        <FTREF/>
                         In many cases, Health IT Modules are key components of these predictive models, often providing the data used to build and train algorithms and serving as the vehicle to influence day-to-day decision-making.
                        <SU>55</SU>
                        <FTREF/>
                         Both 
                        <PRTPAGE P="1232"/>
                        structured and unstructured data generated by, and subsequently made available through, certified Health IT Modules power the training and real-world use of predictive models. Developers of certified health IT also create and deploy predictive algorithms or models for use in production environments through their Health IT Modules and, increasingly, such developers also enable 
                        <E T="03">other parties,</E>
                         including third-party developers and the developer of certified health IT's customers, to create and deploy predictive models through the developer's Health IT Modules.
                        <E T="51">56 57</E>
                        <FTREF/>
                         In turn, certified Health IT Modules are often the vehicle or delivery mechanism for predictive model outputs to reach users, such as clinicians, through clinical decision support.
                        <E T="51">58 59</E>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>54</SU>
                             See, 
                            <E T="03">e.g.,</E>
                             American Hospital Association. “Surveying the AI Health Care Landscape” 2019. 
                            <E T="03">https://www.aha.org/system/files/media/file/2019/10/Market_Insights_AI-Landscape.pdf;</E>
                             Darshali A Vyas, et al., Hidden in plain sight—reconsidering the use of race correction in clinical algorithms § 383 (Mass Medical Soc 2020); Fact Versus Fiction: Clinical Decision Support Tools and the (Mis)use of Race. (2021); Goldhill, Olivia. Artificial intelligence can now predict suicide with remarkable accuracy, Quartz, (July 2022), 
                            <E T="03">https://qz.com/1001968/artificial-intelligence-can-now-predict-suicide-with-remarkable-accuracy/</E>
                             (discussing the use of ML algorithms to predict and prevent suicide).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>55</SU>
                             See, 
                            <E T="03">e.g.,</E>
                             Burdick, Hoyt, et al. “Effect of a sepsis prediction algorithm on patient mortality, length of 
                            <PRTPAGE/>
                            stay and readmission: a prospective multicentre clinical outcomes evaluation of real-world patient data from US hospitals.” 
                            <E T="03">BMJ health &amp; care informatics</E>
                             27.1 (2020).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>56</SU>
                             Landi, H. Epic taps Microsoft to accelerate generative AI-powered `copilot' tools to help clinicians save time. Fierce Healthcare. August 22, 2023 
                            <E T="03">https://www.fiercehealthcare.com/ai-and-machine-learning/epic-expands-ai-partnership-microsoft-rolls-out-copilot-tools-help.</E>
                        </P>
                        <P>
                            <SU>57</SU>
                             See 88 FR 23860 where we discuss that a production environment is generally understood as being the setting where health IT is implemented, run, and relied on by end users in day-to-day conduct of their profession (such as medicine, nursing, or pharmacy) or other business (such as a payer processing healthcare reimbursement claims or a patient managing their health and care).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>58</SU>
                             Fox, A. NextGen introduces AI-enabled ambient listening that syncs with EHR. Healthcare IT News. October 11, 2023. 
                            <E T="03">https://www.healthcareitnews.com/news/nextgen-introduces-ai-enabled-ambient-listening-syncs-ehr.</E>
                        </P>
                        <P>
                            <SU>59</SU>
                             Miliard, M. Oracle Cerner adds generative AI to its EHR platforms. September 19, 2023. 
                            <E T="03">https://www.healthcareitnews.com/news/oracle-cerner-adds-generative-ai-its-ehr-platforms.</E>
                        </P>
                    </FTNT>
                    <P>
                        The National Academy of Medicine (NAM) described in a 2019 report how predictive models and other forms of artificial intelligence (AI) have the potential to represent the “payback” of using health IT “by facilitating tasks that every clinician, patient, and family would want, but are impossible without electronic assistance.” 
                        <SU>60</SU>
                        <FTREF/>
                         The NAM report also identified a crucial “need to present each health care AI tool along with the spectrum of transparency related to the potential harms and context of its use. Evaluating and addressing appropriate transparency, in each sub-domain of data, algorithms, and performance, and systematically reporting it, must be a priority.” 
                        <SU>61</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>60</SU>
                             Michael Matheny, et al., Artificial intelligence in health care: the hope, the hype, the promise, the peril, Washington, DC: National Academy of Medicine (2019).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>61</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <P>
                        In November 2020, the Office of Management and Budget released a Memorandum for the Heads of Executive Departments and Agencies on 
                        <E T="03">Guidance for Regulation of Artificial Intelligence Applications,</E>
                         which directed that “[w]hen considering regulations or policies related to AI applications, agencies should continue to promote advancements in technology and innovation, while protecting American technology, economic and national security, privacy, civil liberties, and other American values, including the principles of freedom, human rights, the rule of law, and respect for intellectual property.” 
                        <SU>62</SU>
                        <FTREF/>
                         This was followed by an executive order in December 2020, E.O. 13960 Promoting the Use of Trustworthy Artificial Intelligence in the Federal Government.
                        <SU>63</SU>
                        <FTREF/>
                         The executive order stated: “The ongoing adoption and acceptance of AI will depend significantly on public trust. Agencies must therefore design, develop, acquire, and use AI in a manner that fosters public trust and confidence while protecting privacy, civil rights, [and] civil liberties[.]” (85 FR 78939).
                    </P>
                    <FTNT>
                        <P>
                            <SU>62</SU>
                             OMB—EOP—Memorandum for the Heads of Executive Departments and Agencies on Guidance for Regulation of Artificial Intelligence M-21-06, p. 6 (Nov. 17, 2020).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>63</SU>
                             E.O. No. 13960, 85 FR 78939: 
                            <E T="03">https://www.federalregister.gov/documents/2020/12/08/2020-27065/promoting-the-use-of-trustworthy-artificial-intelligence-in-the-federal-government.</E>
                        </P>
                    </FTNT>
                    <P>
                        In June 2021, the Government Accountability Office (GAO) published 
                        <E T="03">Artificial Intelligence: An Accountability Framework for Federal Agencies and Other Entities,</E>
                         which specifically outlined key principles and actions “[t]o help entities promote accountability and responsible use of AI systems.” This included outlining four principles for the framework, including governance, data, performance, and monitoring.
                        <SU>64</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>64</SU>
                             GAO, Artificial Intelligence: An Accountability Framework for Federal Agencies and Other Entities: (June 2021), 
                            <E T="03">https://www.gao.gov/assets/gao-21-519sp.pdf.</E>
                             See generally 
                            <E T="03">Artificial Intelligence in Health Care: Benefits and Challenges of Technologies to Augment Patient Care,</E>
                             (Nov. 2020), 
                            <E T="03">https://www.gao.gov/products/gao-21-7sp.</E>
                        </P>
                    </FTNT>
                    <P>
                        In September 2022, the Biden-Harris Administration published 
                        <E T="03">Principles for Enhancing Competition and Tech Platform Accountability,</E>
                         which included a principle related to stopping discriminatory algorithmic decision-making.
                        <SU>65</SU>
                        <FTREF/>
                         In October 2022, the Biden-Harris Administration published a 
                        <E T="03">Blueprint for an AI Bill of Rights,</E>
                         which outlines five principles, informed by public input, that should guide the design, use, and deployment of automated systems to protect the American public in the age of AI. These principles are safe and effective systems; algorithmic discrimination protections; data privacy; notice and explanation; and human alternatives, consideration, and fallback.
                        <SU>66</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>65</SU>
                             See White House, 
                            <E T="03">Principles for Enhancing Competition and Tech Platform Accountability,</E>
                             Sept. 8, 2022, 
                            <E T="03">https://www.whitehouse.gov/briefing-room/statements-releases/2022/09/08/readout-of-white-house-listening-session-on-tech-platform-accountability/</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>66</SU>
                             See White House, 
                            <E T="03">Blueprint for an AI Bill of Rights</E>
                             (October 4, 2022), 
                            <E T="03">https://www.whitehouse.gov/ostp/ai-bill-of-rights/</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        On February 16, 2023, E.O. 14091, Further Advancing Racial Equity and Support for Underserved Communities Through the Federal Government, was issued (88 FR 10825-10833).
                        <SU>67</SU>
                        <FTREF/>
                         E.O. 14091 builds upon previous equity-related executive orders, including E.O. 13985.
                        <SU>68</SU>
                        <FTREF/>
                         Section 1 of E.O. 14091 requires the Federal Government to “promote equity in science and root out bias in the design and use of new technologies, such as artificial intelligence.” Section 8, subsection (f) of E.O. 14091 requires agencies to consider opportunities to “prevent and remedy discrimination, including by protecting the public from algorithmic discrimination.”
                    </P>
                    <FTNT>
                        <P>
                            <SU>67</SU>
                             E.O. 14091, 88 FR 10825-10833: 
                            <E T="03">https://www.federalregister.gov/documents/2023/02/22/2023-03779/further-advancing-racial-equity-and-support-for-underserved-communities-through-the-federal.</E>
                             See 
                            <E T="03">https://www.whitehouse.gov/briefing-room/statements-releases/2023/10/30/fact-sheet-president-biden-issues-executive-order-on-safe-secure-and-trustworthy-artificial-intelligence/</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>68</SU>
                             E.O. 13985, 88 FR 7009: 
                            <E T="03">https://www.federalregister.gov/documents/2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underserved-communities-through-the-federal-government</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        Finally, on October 30, 2023, E.O. 14110, Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence, was issued to ensure that America leads the way in seizing the promise and managing the risks of AI.
                        <SU>69</SU>
                        <FTREF/>
                         This E.O. established directives and priorities for this emerging technology, including, standards for AI safety and security. E.O. 14110 supports responsible AI development and use in healthcare, specifically, and directs HHS to issue a strategic plan on responsible deployment and use of AI and AI-enabled technologies in the health and human services sector that includes “development, maintenance, and availability of documentation to help users determine appropriate and safe uses of AI in local settings in the health and human services sector;” (Section 8, subsection (b)(i)(E)). It likewise directs the Secretary of HHS to develop a strategy to “determine 
                        <PRTPAGE P="1233"/>
                        whether AI-enabled technologies in the health and human services sector maintain appropriate levels of quality, including, as appropriate, in the areas described in subsection (i) of this section. This work shall include the development of AI assurance policy—to evaluate important aspects of the performance of AI-enabled healthcare tools—and infrastructure needs for enabling premarket assessment and post-market oversight of AI-enabled healthcare-technology algorithmic system performance against real-world data (Section 8, subsection (b)(ii)). In addition, E.O. 14110 directs HHS to establish a safety program to receive reports of—and act to remedy—harms or unsafe healthcare practices involving AI (Section 8, subsection (b)(iv)).
                        <SU>70</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>69</SU>
                             E.O. 14110. 88 FR 75191: 
                            <E T="03">https://www.federalregister.gov/documents/2023/11/01/2023-24283/safe-secure-and-trustworthy-development-and-use-of-artificial-intelligence.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>70</SU>
                             In addition to the E.O., on November 1, the Office of Management and Budget (OMB) released draft guidance for federal agencies, “Advancing Governance, Innovation, and Risk Management for Agency Use of Artificial Intelligence” available at: 
                            <E T="03">https://ai.gov/wp-content/uploads/2023/11/AI-in-Government-Memo-Public-Comment.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        A growing body of peer-reviewed evidence, technical and socio-technical expert analyses, and government activities and reports focus on ensuring that the promise of AI and machine learning can equitably accelerate advancements in healthcare to improve the health and well-being of the American public.
                        <SU>71</SU>
                        <FTREF/>
                         The Department has a longstanding interest in understanding and addressing concerns about negative, adverse, or harmful consequences that may result from the use of digital data or information about individuals' health (including data analytics), including historically, their use in computerized decision-making.
                        <SU>72</SU>
                        <FTREF/>
                         As such, we proposed in the HTI-1 Proposed Rule (88 FR 23774-23811) to incorporate new requirements into the Program for Health IT Modules that support the execution of AI or machine learning-based technology in support of decision-making as part of the revised CDS criterion in § 170.315(b)(11). These requirements align with the Federal Government's efforts to promote trustworthy AI and the Department's stated policies on advancing equity in the delivery of health and human services.
                        <SU>73</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>71</SU>
                             We discuss additional federal and HHS activities—including activities resulting from the executive orders—in the subsection below entitled “Relationship to Other Federal Agencies' Relevant Activities, Interests, and Regulatory Authority.”
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>72</SU>
                             See 
                            <E T="03">e.g.,</E>
                             U.S. Dep't. of Health, Education, &amp; Welfare (HEW), Secretary's Advisory Committee on Automated Personal Data Systems, Records, Computers, and the Rights of citizens viii (1973) 
                            <E T="03">https://aspe.hhs.gov/report/records-computers-and-rights-citizens https://aspe.hhs.gov/report/records-computers-and-rights-citizens</E>
                             (The origination of the code of fair information practices, more commonly known as the fair information practice principles (FIPPs)).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>73</SU>
                             HHS, Statements on New Plan to Advance Equity in the Delivery of Health and Human Services, April 14, 2022, 
                            <E T="03">https://www.hhs.gov/about/news/2022/04/14/hhs-statements-on-new-plan-advance-equity-delivery-health-human-services.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        We believe that the continued evolution of decision support software, especially as it relates to AI or machine learning-driven Predictive DSIs, necessitates new requirements for the Program's CDS criterion. We therefore proposed requirements for new sets of information that are necessary to guide decision-making based on outputs (
                        <E T="03">e.g.,</E>
                         recommendations) from Predictive DSIs, such as an expanded set of “source attributes” and information related to how risk is managed by developers of certified health IT (88 FR 23775). We believe that these new sets of information will provide appropriate information to help guide decisions at the time and place of care, consistent with 42 U.S.C. 300jj-11(b)(4).
                    </P>
                    <P>
                        In the HTI-1 Proposed Rule (88 FR 23746), we provided an overview of the history, current uses, and risks associated with predictive algorithms and models in healthcare. We refer readers to section III.C.5 of the HTI-1 Proposed Rule for the details of those discussions (88 FR 23776 through 23781). We noted our goal with the proposals, described herein and as aligned with our authority, was to assist in addressing the gaps between the promise and peril of AI in health articulated in the National Academy of Medicine report 
                        <SU>74</SU>
                        <FTREF/>
                         discussed in the HTI-1 Proposed Rule (88 FR 23780).
                    </P>
                    <FTNT>
                        <P>
                            <SU>74</SU>
                             Michael Matheny, et al., Artificial intelligence in health care: the hope, the hype, the promise, the peril, Washington, DC: National Academy of Medicine (2019).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Objectives of the Policies To Address Predictive Modeling in DSI</HD>
                    <P>In the HTI-1 Proposed Rule at 88 FR 23780-23781, we noted that the proposals for § 170.315(b)(11) were intended to introduce much-needed information transparency to address uncertainty regarding the quality of Predictive DSIs that Health IT Modules certified to the criterion in § 170.315(b)(11) support. We noted that doing so would equip potential users with sufficient information about how a Predictive DSI was designed, developed, trained, and evaluated to determine whether it was trustworthy (88 FR 23780). We proposed a dual emphasis for transparency on (1) the technical and performance aspects of Predictive DSIs and (2) the organizational competencies employed to manage risks for Predictive DSIs. Together, this information would support potential users in making better informed decisions about whether and how to use Predictive DSIs in their decision-making given the specifics of their context, patients, and needs. We noted that we considered the information included in these proposed requirements as a prerequisite to determine the quality of predictive models. We explained that our proposals were not aimed at approving or guaranteeing the quality of Predictive DSIs or the models on which they are based. Instead, the proposals were intended to provide users and the public with greater information, available in a consistent manner, on whether a Predictive DSI is fair, appropriate, valid, effective, and safe (FAVES). We anticipated that a long-term outcome of such transparency would be increased public trust and confidence in Predictive DSIs. As a result of new transparency, we anticipated that users, including healthcare systems, clinicians, and patients, would be able to expand the use of these technologies in safer, more appropriate, and more equitable ways.</P>
                    <P>
                        We did not propose to establish or define regulatory baselines, measures, or thresholds for FAVES (88 FR 23780). Instead, we proposed to establish requirements in § 170.315(b)(11) to make information available that would enable users, based on their own judgment, to determine if a Predictive DSI, that is supported by a Health IT Module, is acceptably fair, appropriate, valid, effective, and safe. We conveyed our understanding that numerous and parallel efforts led by industry groups and academia were developing methods to evaluate Predictive DSIs for fairness, appropriateness, validity, effectiveness, and safety, among other kinds of evaluations. Moreover, we noted that we understood that these efforts were also identifying means to communicate measures of FAVES through model cards,
                        <SU>75</SU>
                        <FTREF/>
                         model nutrition labels,
                        <SU>76</SU>
                        <FTREF/>
                         datasheets,
                        <SU>77</SU>
                        <FTREF/>
                         data cards,
                        <SU>78</SU>
                        <FTREF/>
                         or algorithmic audits.
                        <SU>79</SU>
                        <FTREF/>
                         However, we also 
                        <PRTPAGE P="1234"/>
                        noted that these efforts lacked consensus and have not been widely or consistently implemented to date. We described that we thought it would be premature to propose requirements for specific measures or thresholds for FAVES. Rather, we stated that the proposed requirements would enable consistent and routine access to technical and performance information specifically relevant to FAVES, which would support users in making informed decisions about whether and how to use Predictive DSIs. While we stressed that transparency regarding the technical and performance dimensions of Predictive DSIs was needed, we also believed that transparency regarding the organizational and socio-technical competencies employed by those who develop Predictive DSIs was foundational for users to determine whether their Predictive DSI is FAVES. Therefore, in addition to the proposed requirements for Predictive DSI-specific source attributes, we also proposed that developers of certified health IT with Health IT Modules that enable or interface with Predictive DSIs employ or engage in intervention risk management practices, subsequently making summary information about these practices publicly available.
                        <SU>80</SU>
                        <FTREF/>
                         We proposed three intervention risk management practices: (1) risk analysis, (2) risk mitigation, and (3) governance (88 FR 23780). Overall, we identified these as practices that promote transparency regarding how the developer of certified health IT analyzes and mitigates risks at the organization level, including proposals that would have such developers establish policies and implement controls for governance, inclusive of how data are acquired, managed, and used in Predictive DSIs. Together, transparency regarding the technical and performance details of a Predictive, as well as the organizational competencies of the developer of certified health IT to manage risks for a Predictive DSI, were intended to contribute to the trustworthiness of these emerging and important technologies.
                    </P>
                    <FTNT>
                        <P>
                            <SU>75</SU>
                             Mitchell, Margaret, et al. “Model cards for model reporting.” Proceedings of the conference on fairness, accountability, and transparency. 2019.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>76</SU>
                             Sendak MP, Gao M, Brajer N, Balu S. Presenting machine learning model information to clinical end users with model facts labels. NPJ Digit Med. 2020 Mar 23;3:41. Doi: 10.1038/s41746-020-0253-3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>77</SU>
                             Gebru, Morgenstern, Vecchione, et al, Datasheets for Datasets, 
                            <E T="03">https://arxiv.org/abs/1803.09010.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>78</SU>
                             FaccT `22: 2022 ACM Conference on Fairness, Accountability, and Transparency (June 2022) Pages 1776-1826, 
                            <E T="03">https://dl.acm.org/doi/proceedings/10.1145/3531146.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>79</SU>
                             See lag Guszcza, et al., Why We Need to Audit Algorithms. Harvard Business Review. Nov. 28, 
                            <PRTPAGE/>
                            2018. 
                            <E T="03">https://hbr.org/2018/11/why-we-need-to-audit-algorithms;</E>
                             Xiaoxuan Liu, et al., 
                            <E T="03">The medical algorithmic audit,</E>
                             The Lancet Digital Health (2022). See generally Outsider Oversight: Designing a Third-Party Audit Ecosystem for AI Governance, ID Raji, P Xu, C Honigsberg, D Ho—Proceedings of the 2022 AAAI/ACM Conference on AI, 2022, 
                            <E T="03">https://dl.acm.org/doi/pdf/10.1145/3514094.3534181.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>80</SU>
                             Public availability and transparency aims align with the OSTP Memorandum to federal departments and agencies (August 2022): “Ensuring Free, Immediate, and Equitable Access to Federally Funded Research” 
                            <E T="03">https://www.whitehouse.gov/wp-content/uploads/2022/08/08-2022-OSTP-Public-access-Memo.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        We noted at 88 FR 23780-23781 that the proposed requirements for the certification criterion in § 170.315(b)(11) also supported health equity by design,
                        <SU>81</SU>
                        <FTREF/>
                         for example, (1) emphasizing transparency regarding the use of specific data elements relevant to health equity 
                        <SU>82</SU>
                        <FTREF/>
                         in Predictive DSIs; (2) enabling users to review whether and how the Predictive DSI was tested for fairness; and (3) enabling transparency about how developers of certified health IT manage risks related to fairness for the Predictive DSIs their Health IT Modules enable or interface with.
                    </P>
                    <FTNT>
                        <P>
                            <SU>81</SU>
                             See “Embracing Health Equity by Design” ONC, February 2022: 
                            <E T="03">https://www.healthit.gov/buzz-blog/health-it/embracing-health-equity-by-design.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>82</SU>
                             See HHS's Strategic Approach to Addressing Social Determinants of Health to Advance Health Equity—At a Glance (April 2022), 
                            <E T="03">https://aspe.hhs.gov/sites/default/files/documents/aabf48cbd391be21e5186eeae728ccd7/SDOH-Action-Plan-At-a-Glance.pdf.</E>
                        </P>
                    </FTNT>
                    <P>At 88 FR 23781, we noted our belief that the existing scope and structure of the Program were fit for these purposes because the Program has existing requirements to make information transparent regarding the authorship, bibliography, and other kinds of “source attribute” information for evidence-based decision support and linked referential intervention types (at § 170.315(a)(9)(v)(A) and (B), respectively). We proposed to build on these requirements so that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) would need to enable user review of evidence-based and Predictive DSIs within their certified products, and to disclose approach(es) to intervention risk management in a publicly accessible manner. Together, we said these requirements would have an important impact on the Department's efforts to address disparities and bias that may be propagated through DSIs. Consequently, we hoped to enhance market transparency and encourage trust across the software development life cycle (SDLC) of DSIs in healthcare. We said this transparency would serve as a foundation for establishing consistency in information availability, improving overall data stewardship, and guiding the appropriate use of data derived from health information about individuals.</P>
                    <P>At 88 FR 23781, we noted that we were intentional regarding the level of prescriptiveness in our proposals because these are nascent technologies with enormous potential benefit. Thus, we sought to establish appropriate guardrails for information transparency about Predictive DSIs that do not undercut the value that could be offered to patients and clinicians from such promising technologies.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters were largely supportive of our DSI proposals but mixed in their support of the specifics of the DSI certification criterion we proposed in § 170.315(b)(11). Most commenters stated that our proposals would increase transparency and accountability, enhance trustworthiness in AI and machine learning-driven decision support tools, and promote risk management by developers of certified health IT. Several commenters stated that these benefits would lead to equitable access to healthcare, contribute to reducing health disparities during provider-patient encounters, increase user and patient trust, and enhance patient experience. Commenters commended ONC's efforts to prevent bias and discriminatory outcomes driven by DSIs and noted that a regulatory framework must be created whereby tools are appropriately tested and vetted during their development, and products are labeled to provide users with essential information.
                    </P>
                    <P>
                        Several commenters applauded our effort to address transparency of rapidly evolving AI in healthcare. Commenters noted that adding new requirements for transparency around DSI applications' technical information, risk management processes, and real-world testing are all foundational steps in establishing these tools' safe and effective use. Several commenters agreed with our proposal that biases in the data and algorithms underlying AI or machine learning could negatively impact certain subpopulations and supported more rigorous evaluation of such tools to ensure that they are fair, effective, and support improved outcomes for patient populations. Specifically, commenters remarked that greater transparency, including about the datasets used to train a Predictive DSI, would help avoid embedding bias in the system and help improve efficiency. Several commenters noted that the HTI-1 Proposed Rule would help lay the foundations for responsible, ethical AI development in healthcare and for enhanced federal AI transparency and will promote establishing necessary assurances for greater trust in AI use. Commenters acknowledged that due to the leaps in technological innovations, especially as it relates to predictive models, it is necessary to have new requirements for the Program's CDS criterion. Several commenters agreed that it is critical for the end user to understand how a Predictive DSI is designed, developed, trained, and evaluated; and how it should be used by the end-user.
                        <PRTPAGE P="1235"/>
                    </P>
                    <P>Commenters approved of the proposal separately looking at risk analysis, risk mitigation, and governance as essential tasks in ensuring proper DSI development, management, and use. Commenters observed that the proposal, if adopted, would provide the opportunity for transparent, thoughtful decision-making by enabling users, including medical practitioners, health care providers, and other interested parties of AI and algorithmic tools to evaluate, disclose, and mitigate risks that could impact patients. Lastly, commenters urged ONC to be mindful that regulations on AI should not stifle innovation or have a chilling effect on beneficial uses of this emerging tool, and that we should seek to balance the risks and benefits to consumers of the public availability of information with the need to protect certain data to comply with the HIPAA Privacy Rule and limit adverse effects from a clinical standpoint.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their broad support of our proposals. We appreciate that many commenters understood our policy objectives and agreed with our proposals to improve trustworthiness through transparency in support of decision-making using AI machine learning-driven tools. We agree with and thank commenters who noted that greater transparency, including about the datasets used to train Predictive DSI, would help avoid embedding bias in the system and help improve efficiency. We are also mindful of the need to balance prescriptiveness and flexibility in our requirements for developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) and have made several modifications to our proposals, described in detail in subsequent responses, to achieve this balance.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concern that the proposed requirements were not strong enough to ensure DSIs are designed with equity in mind and fully validated for all patient populations when deployed and believed the HTI-1 Proposed Rule did not ensure developer accountability. One commenter was concerned that the proposal did not address or require equity testing across patient populations to limit potential biases.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters concerns. We have finalized several requirements that will help promote DSIs to be designed with health equity in mind, and we have finalized specific requirements related to performance measures of validity and fairness.
                        <SU>83</SU>
                        <FTREF/>
                         Our proposal sought to ensure that information would be available for users to easily review whether a given model has been adequately validated and tested for fairness before using it, as well as enable users to understand if a DSI used data elements relevant to health equity, such as race, ethnicity, and sexual orientation, among other data elements.
                        <SU>84</SU>
                        <FTREF/>
                         We clarify that nothing from our proposals nor our finalized criterion would require a user of a Health IT Module certified to § 170.315(b)(11) to review source attributes, though we also note that certain users may already have an existing obligation to ensure compliance with non-discrimination requirements and comply with applicable law.
                        <SU>85</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>83</SU>
                             See § 170.315(b)(11)(iv)(B)(v)(
                            <E T="03">5</E>
                            )-(
                            <E T="03">9</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>84</SU>
                             See § 170.315(b)(11)(iv)(A)(
                            <E T="03">5</E>
                            )-(
                            <E T="03">13</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>85</SU>
                             See U.S. Dept of Health &amp; Human Servs., Office for Civil Rights, Notice of Proposed Rulemaking, Nondiscrimination in Health Programs and Activities, 87 FR 47824, 47880 (Aug. 4, 2022), 
                            <E T="03">https://www.federalregister.gov/documents/2022/08/04/2022-16217/nondiscrimination-in-health-programs-and-activities</E>
                             (prohibiting discrimination on the basis of race, color, national origin (including limited English proficiency), sex (including sexual orientation and gender identity), age, or disability in certain health programs or activities 
                            <E T="03">through the use of clinical algorithms in their decision-making</E>
                            ); Title VI of the Civil Rights Act of 1964, 42 U.S.C. 2000d 
                            <E T="03">et seq.</E>
                             (prohibiting discrimination on the basis of race, color, or national origin (including limited English proficiency) in federally funded programs or activities); Title IX of the Education Amendments of 1972, 20 U.S.C. 1681 
                            <E T="03">et seq.</E>
                             (prohibiting sex discrimination in federally funded education programs or activities); the Age Discrimination Act of 1975, 42 U.S.C. 6101 
                            <E T="03">et seq.</E>
                             (prohibiting age discrimination in federally funded programs or activities); Section 504 of the Rehabilitation Act of 1973, 29 U.S.C. 794 (prohibiting disability discrimination in federally funded or federally conducted programs or activities); and the Americans with Disabilities Act, 42 U.S.C. 12101 
                            <E T="03">et seq.</E>
                             (prohibiting disability discrimination by employers, state and local government entities, and businesses that are open to the public, among others).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         A minority of commenters did not support the proposed revised DSI certification criterion, noting that it was premature for ONC to adopt policies related to AI or machine learning. Some commenters expressed a belief that ONC's proposed revised DSI certification criterion's requirements would exceed ONC's authority, questioned whether ONC had the authority to impose non-quality or efficacy criteria on Predictive DSI, and believed there was not sufficient statutory support for the proposed revisions to DSI or authority over non-certified software that is enabled by or interfaces with certified health IT. In particular, commenters noted that ONC's authority to adopt certification criteria is provided by section 3001(c)(5)(D) of the PHSA and that the HTI-1 Proposed Rule would make changes to the architecture of health software used by thousands of hospitals and health providers across the country, including software that would not be directly part of the Program. Commenters also requested that ONC address how each of its proposed changes fit within the subcategories permitted by section 3001(c)(5)(D) of the PHSA.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We disagree with commenters who believe that requirements for AI or machine learning-driven decision support is premature. Given the proliferation of such tools used in healthcare and supplied by developers of certified health IT, we believe now is an opportune time to help optimize the use and improve the quality of AI and machine learning-driven decision support tools. Moreover, our statutory authority to promulgate regulations to define certification criteria for the Program is established in 42 U.S.C. 300jj-11(c)(5)(A) and 300jj-14(b). The authority in 42 U.S.C. 300jj-11(c)(5)(D) of the PHSA was added by section 4002(a) of the Cures Act and is specific to conditions of certification under the Program, which does not limit the scope of the Program and, in fact, expanded the scope and applicability of the Program with respect to developers of certified health IT. Moreover, since 2010, the Program has included a certification criterion related to decision support in response to the definition established by Congress for 
                        <E T="03">qualified electronic health record,</E>
                         in 42 U.S.C. 300jj(13)(B)(i).
                        <SU>86</SU>
                        <FTREF/>
                         At the time Congress included this specific capability within the 
                        <E T="03">qualified electronic health record</E>
                         definition, it did so without specific limits and in the context of the broader HITECH Act, and subsequently the Cures Act, with the understanding that technology changes over time and so too would certification criteria. Finally, we note that our authority to propose and finalize revisions to the Program's DSI criterion is consistent with 42 U.S.C. 300jj-(c)(5) and fulfills several purposes enumerated by Congress in 42 U.S.C. 300jj-(b). The finalized requirements in § 170.315(b)(11), consistent with our authority, substantially focus on the responsibilities of developers of certified health IT and the products these developers bring forward for certification. Specifically, the updated criterion includes new sets of information that are necessary to guide 
                        <PRTPAGE P="1236"/>
                        decision-making based on outputs (
                        <E T="03">e.g.,</E>
                         recommendations) from Predictive DSIs, including:
                    </P>
                    <FTNT>
                        <P>
                            <SU>86</SU>
                             ONC finalized in § 170.304(e) the “clinical decision support” certification criteria in the interim final rule, “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology,” January 13, 2010 (75 FR 2014).
                        </P>
                    </FTNT>
                    <P>• An expanded set of “source attributes” in § 170.315(b)(11)(iv);</P>
                    <P>• Requirements for Health IT Modules to enable a limited set of identified users to access complete and up-to-date plain language descriptions of source attribute information in § 170.315(b)(11)(v);</P>
                    <P>• Requirements for intervention risk management practices to be applied for each Predictive DSI supplied by the health IT developer as part of its Health IT Module in § 170.315(b)(11)(vi); and</P>
                    <P>• Requirements for summary information related to how intervention risk is managed to be publicly accessible in § 170.523(f)(1)(xxi).</P>
                    <P>We believe that these new sets of information will provide appropriate information to help guide decisions at the time and place of care, consistent with 42 U.S.C. 300jj-11(b)(4). Additionally, our finalized policies in §§ 170.315(b)(11), 170.402(b)(4), and 170.523(f)(1)(xxi) will support several other Congressionally-identified purposes that inform the National Coordinator's work in carrying out their duties, including the duty identified in 42 U.S.C. 300jj-11(c)(5)(A). These additional purposes include 42 U.S.C. 300jj-11(b)(2), “improves health care quality, reduces medical errors, reduces health disparities, and advances the delivery of patient-centered medical care”; 42 U.S.C. 300jj-11(b)(8), “facilitates health and clinical research and health care quality”; 42 U.S.C. 300jj-11(b)(10), “promotes a more effective marketplace, greater competition, greater systems analysis, increased consumer choice, and improved outcomes in health care services”; and 42 U.S.C. 300jj-11(b)(11), “improves efforts to reduce health disparities.”</P>
                    <P>In consideration of all the public comments received, and aligned with both the authorities granted by Congress and directives established by several Executive Orders, we have finalized most of our proposals for § 170.315(b)(11) with modifications intended to align and simplify technical requirements between evidence-based DSIs and Predictive DSIs as well as to clarify: (1) the definition of Predictive DSI in § 170.102; (2) the scope of technologies considered to be an evidence-based DSI for purposes of the Program; and (3) the scope of source attribute information that must be accessible to users. Specifically, we have finalized our proposals by significantly narrowing the scope of requirements for Predictive DSI-related source attributes and intervention risk management (IRM) practices to apply only to Predictive DSIs supplied by the health IT developer as part of its Health IT Module. In addition to the detailed section-by-section final rule discussions, the following paragraphs summarize some of the key policy determinations included in this final rule.</P>
                    <P>Additionally, in consideration of comments received and the scope reductions we have made to this final certification criterion, we determined that a supportive Maintenance of Certification requirement as part of the Assurances Condition of Certification is necessary to fully implement our policy objectives and proposals. Specifically, we have finalized in this final rule an “Assurances” Maintenance of Certification requirement at 45 CFR 170.402(b)(4) that starting January 1, 2025, and on an ongoing basis thereafter, health IT developers with Health IT Modules certified to § 170.315(b)(11) review and update as necessary, source attribute information in § 170.315(b)(11)(v)(A) and (B), risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi). This reinforces a health IT developer's ongoing responsibility to enable users to access complete and up-to-date descriptions of DSI source attribute information at § 170.315(b)(11)(v)(A) and (B) to review and update as necessary IRM practices for all Predictive DSIs it supplies as part of its Health IT Module, and to ensure the ongoing public availability of summary IRM practice information as submitted to their ONC-ACB via hyperlink in § 170.523(f)(1)(xxi). We have finalized that developers with Health IT Modules certified to § 170.315(b)(11) will need to comply with this Maintenance of Certification requirement starting January 1, 2025. We added this Maintenance of Certification requirement to serve as a discrete connection for developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) to ensure that their Health IT Modules have complete and up-to-date descriptions of source attribute information and other required information, both at the time of certification and on an ongoing basis while their Health IT Modules are certified to § 170.315(b)(11).</P>
                    <P>
                        We have 
                        <E T="03">not</E>
                         finalized proposals related to the proposed Predictive DSI attestation statement, and we will 
                        <E T="03">not</E>
                         require Health IT Modules certified to § 170.315(b)(11) to support linked referential DSIs or related source attributes under the Program. Further, we have finalized modifications to our proposal for IRM practices in § 170.315(b)(11)(vi) and did 
                        <E T="03">not</E>
                         adopt the requirement for detailed documentation we proposed in § 170.315(b)(11)(vi)(B). The finalized § 170.315(b)(11)(vi) requires that IRM practices must be applied for each Predictive DSI supplied by the health IT developer as part of its Health IT Module, which is similar to how we described the proposal in § 170.315(b)(11)(vii)(A) in the HTI-1 Proposed Rule (88 FR 23798).
                    </P>
                    <P>We have also finalized in § 170.102, as proposed, the date for which the requirements of § 170.315(b)(11) must be satisfied for Health IT Modules to meet the definition of Base EHR. This means that proposed changes to the Base EHR definition in § 170.102 that would allow a Health IT Module to meet said definition if it has been certified to § 170.315(a)(9) or (b)(11) for the period up to and including December 31, 2024, and § 170.315(b)(11) on and after January 1, 2025, have been finalized as proposed. This also means that a developer of certified health IT with a Health IT Module certified to § 170.315(b)(11) must apply IRM practices for each Predictive DSI supplied by the health IT developer as described in § 170.315(b)(11)(vi) and submit summary information of their IRM practices to its ONC-ACB via publicly accessible hyperlink according to § 170.523(f)(1)(xxi) before December 31, 2024. We note that we have finalized, as discussed in section III.C.5.a.xiv, that the adoption of the criterion at § 170.315(a)(9) for purposes of the ONC Health IT Certification Program expires on January 1, 2025.</P>
                    <P>Together, these modifications reflect feedback received from numerous interested parties and are in response to both their support and opposition to our proposals. They are also intended to simplify Program requirements and support practical implementation of the certification criterion by developers of certified health IT. We elaborate on the details of these and other finalized policies more fully in subsequent responses of this final rule.</P>
                    <HD SOURCE="HD3">a. Requirements for Decision Support Interventions (DSI) Certification Criterion</HD>
                    <HD SOURCE="HD3">i. Structural Revisions and New Criterion Categorization</HD>
                    <P>
                        We proposed at 88 FR 23782 through 23783 to adopt the certification criterion “decision support interventions,” (DSI) in § 170.315(b)(11) as a “revised certification criterion” according to the 
                        <PRTPAGE P="1237"/>
                        proposed definition in § 170.102. The proposed criterion in § 170.315(b)(11) was a revised version of 45 CFR 170.315(a)(9), “clinical decision support (CDS).” In § 170.315(b)(11), we proposed to adopt a substantially similar structure as is currently in § 170.315(a)(9). In the revised certification criterion at § 170.315(b)(11), we proposed to modify the existing requirements in § 170.315(a)(9) to reflect an array of contemporary functionalities, data elements, and software applications that certified Health IT Modules support to aid decision-making in healthcare. We proposed that the policies established in § 170.315(a)(9)(i) through (iv) would be included as § 170.315(b)(11)(i) through (iv) with modifications. We proposed to introduce a new intervention type in § 170.315(b)(11), Predictive DSIs, with a corresponding definition in § 170.102 for the term.
                    </P>
                    <P>At 88 FR 23782, we discussed our rationale for these proposals and stated our view that proposed § 170.315(b)(11) reflected functionality that is better categorized as part of the “care coordination certification criteria,” as opposed to the “clinical certification criteria,” supported by the Program. Hence, we proposed to adopt the “decision support intervention” certification criterion in the “care coordination criteria” section adopted within § 170.315(b).</P>
                    <P>At 88 FR 23783, we proposed modifications to the Base EHR definition in § 170.102 to identify the dates when § 170.315(b)(11) would replace § 170.315(a)(9) in the Base EHR definition. In keeping with the proposal to modify the Base EHR definition in § 170.102, we proposed that the adoption of § 170.315(a)(9) as part of the Program would expire on January 1, 2025. We noted that if we finalized these proposals, developers of certified health IT with Health IT Modules certified to § 170.315(a)(9) would need to certify those Health IT Modules to § 170.315(b)(11) in order for those Health IT Modules to continue to meet the Base EHR definition. Lastly, as a consequence of the proposed adoption of this criterion in § 170.315(b), we noted that developers of certified health IT with Health IT Module(s) certified to § 170.315(b)(11) would be required to submit real world testing plans and corresponding real world testing results, consistent with § 170.405.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters' support was split with respect to the proposal to adopt the certification criterion naming update of “decision support interventions,” or DSI, for § 170.315(b)(11) as a “revised certification criterion” of 45 CFR 170.315(a)(9), “clinical decision support” (CDS). Commenters in support noted that the proposal would promote greater trust in DSI and predictive models through the Program. Commenters stated that distinguishing between CDS and DSI was warranted and that with the technological advancements in predictive analytics, AI, and machine learning, the certification criterion needed to be updated to better reflect the market, and our proposal reflected contemporary and emerging functions, uses, and data elements. Commenters who did not support the proposal recommended against renaming clinical decision support to decision support interventions because they stated the term “intervention” has other meanings within healthcare. Commenters suggested that retaining the name “clinical decision support” aligns better with the clinical decision support included in the legislative definition of a 
                        <E T="03">qualified electronic health record.</E>
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' support for our proposal and agree that revising the existing CDS criterion in § 170.315(a)(9) as the DSI criterion in § 170.315(b)(11) is reflective of how decision support relies on increasing technological advancements in predictive analytics, AI, and machine learning. We agree the Program should be updated to reflect these advancements. While we appreciate the concerns raised regarding renaming the criterion from Clinical Decision Support to Decision Support Interventions, we note that the term “evidence-based decision support intervention,” has been part of the Program for nearly a decade, and we believe that removing “clinical” reflects the reality that Health IT Modules already support a broad array of decision support beyond what has been traditionally considered CDS. We also believe that the DSI criterion will continue to support the legislative definition of a 
                        <E T="03">qualified electronic health record</E>
                         as it has since the inception of the Program. We note our discussion of the term “intervention” was described in 88 FR 23786 and that the Program's use of the term “intervention” is different from “clinical intervention” as defined under FDA regulation that includes a range of regulated products, such as a medication or medical device. We discuss the term “intervention” in more detail in subsequent responses.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters suggested that ONC make Predictive DSI support a separate certification criterion from the existing “clinical decision support” criterion to better facilitate it being on a more extended timeframe for implementation and potentially impacting different products, whereas other commenters were supportive of revising the criterion to account for the rapid changes in this area of health IT.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments, but we decline to create a separate certification criterion for Predictive DSIs. We believe that the current structure of the CDS criterion in § 170.315(a)(9) is suitable to be implemented in a revised version in § 170.315(b)(11) and that this approach is more straight-forward than having substantially similar yet separate criteria. We have not extended the timeframe for implementation from what we proposed because many of the capabilities we have finalized in § 170.315(b)(11) are substantially similar to what already exists in § 170.315(a)(9) and because we have made other corresponding scope adjustments to the finalized certification criterion. We agree with commenters who note that technology is changing rapidly and there is a need for these policies to be implemented on a more accelerated timeline from other requirements in the HTI-1 Proposed Rule.
                    </P>
                    <P>After consideration of these comments, we have finalized our proposal to adopt the “DSI certification criterion” in § 170.315(b)(11) as a “revised certification criterion” according to the proposed definition in § 170.102 and as part of the “care coordination certification criteria,” in § 170.315(b), including paragraph (b)(11)(i), which remains unchanged from paragraph (a)(9)(i). We have also finalized inclusion of the certification criterion at § 170.315(b)(11) as part of the Base EHR definition in § 170.102, and that beginning January 1, 2025, the certification criterion at § 170.315(a)(9) would not be included in that definition. Among the numerous standards and certification criteria proposed for revision by the end of 2024, the certification criterion in § 170.315(b)(11) has been prioritized and finalized on the proposed timeline. Based on public comment, we have lengthened the implementation timeline for nearly every other standard and certification criterion proposed in the HTI-1 Proposed Rule, as well as made other timing adjustments that could impact prioritization for § 170.315(b)(11). We believe these final rule updates will give developers of certified health IT time to focus on implementing the DSI criterion at § 170.315(b)(11).</P>
                    <P>
                        Finally, as we noted in the HTI-1 Proposed Rule (88 FR 23783), as a consequence of adopting this revised 
                        <PRTPAGE P="1238"/>
                        criterion in § 170.315(b), developers of certified health IT with Health IT Module(s) certified to § 170.315(b)(11) are required to submit real world testing plans and corresponding real world testing results, consistent with § 170.405, demonstrating the real world use of each type of DSI in § 170.315(b)(11), including evidence-based DSIs and Predictive DSIs. Finally, as we noted in the HTI-1 Proposed Rule (88 FR 23783), as a consequence of adopting this revised criterion in § 170.315(b), developers of certified health IT with Health IT Module(s) certified to § 170.315(b)(11) are required to submit real world testing plans and corresponding real world testing results, consistent with § 170.405, demonstrating the real-world use of each type of DSI in § 170.315(b)(11), including evidence-based DSIs and Predictive DSIs.
                    </P>
                    <HD SOURCE="HD3">ii. Decision Support Configuration</HD>
                    <P>
                        At 88 FR 23783, we proposed in § 170.315(b)(11)(ii) to establish “decision support configuration” requirements based on what is currently in § 170.315(a)(9)(ii) with modifications and additional requirements. To reflect ONC's focus on the USCDI and to acknowledge the varied data for which DSIs may be enabled, we proposed that data elements listed in § 170.315(b)(11)(ii)(B)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) through (
                        <E T="03">iii</E>
                        ) and (
                        <E T="03">v</E>
                        ) through (
                        <E T="03">viii</E>
                        ) be expressed according to the standards expressed in § 170.213, including the proposed USCDI v3. We proposed to reference the USCDI in § 170.315(b)(11)(ii)(B)(
                        <E T="03">1</E>
                        ) to define the scope of the data “at a minimum.” We noted the intention was to establish baseline expectations that Health IT Modules certified to § 170.315(b)(11) must be capable of supporting DSIs that use those data elements listed in § 170.315(b)(11)(ii)(B)(
                        <E T="03">1</E>
                        ). We did not propose to establish requirements for specific interventions to be supported, only that Health IT Modules certified to § 170.315(b)(11) be capable of supporting interventions that use those listed data elements. This proposed requirement was framed to pertain to both evidence-based DSIs and Predictive DSIs that would be enabled by or interfaced with a certified Health IT Module, including any Predictive DSIs that were developed by users of the certified Health IT Module. We proposed to adopt in § 170.315(b)(11) the existing reference in § 170.315(a)(9)(ii)(B)(
                        <E T="03">1</E>
                        )(
                        <E T="03">iv</E>
                        ) to demographic data in § 170.315(a)(5)(i).
                    </P>
                    <P>
                        Additionally, at 88 FR 23783 we proposed to include two USCDI data classes not currently found in § 170.315(a)(9)(ii)(B)(
                        <E T="03">1</E>
                        ). In § 170.315(b)(11)(ii)(B)(
                        <E T="03">1</E>
                        )(
                        <E T="03">vii</E>
                        )-(
                        <E T="03">viii</E>
                        ), we proposed to include the Unique Device Identifier(s) for a Patient's Implantable Device(s) and Procedures data classes, respectively, as expressed in the standards in § 170.213, including the proposed USCDI v3. We proposed to require that Health IT Modules would support data from the Procedures data class and the Unique Device Identifier(s) for a Patient's Implantable Device(s) data class as an input to DSIs. We invited comment on the additional data classes described in § 170.315(b)(11)(ii)(B)(
                        <E T="03">1</E>
                        )(
                        <E T="03">vii</E>
                        ).
                    </P>
                    <P>At 88 FR 23784, we proposed to adopt in § 170.315(b)(11)(ii)(C) a new functionality to enable users to provide electronic feedback data based on the information displayed through the DSI. We proposed that a Health IT Module certified to § 170.315(b)(11) must be able to export such feedback data, including but not limited to the intervention, action taken, user feedback provided (if applicable), user, date, and location, so that the exported data could be associated with other relevant data.</P>
                    <P>
                        At 88 FR 23784, we proposed that such feedback data be available for export by users for analysis in a computable format, so that it could be associated with other relevant data. We noted that “computable format,” was consistent with current requirements in § 170.315(b)(10)(i)(D) for EHI Export, and we clarified that “computable format” is also referred to as “machine readable,” in other contexts, which is not synonymous with “digitally accessible.” 
                        <SU>87</SU>
                        <FTREF/>
                         We did not propose to require specific formatting requirements for such feedback mechanisms.
                    </P>
                    <FTNT>
                        <P>
                            <SU>87</SU>
                             See also 85 FR 25879 discussion of machine readable.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters expressed support for the proposal to define the scope of data and supported the inclusion of USCDI v3 as the minimum set of data that should be included stating that defining data elements according to the USCDI v3 standard would have the benefit of improving transparency and increasing accuracy. Commenters recommended ONC support alignment efforts with standards development organizations (SDOs) and convene listening sessions with DSI developers to align reporting efforts and to understand the appropriate minimum base sets of data for DSI technology. One commenter expressed concern that the proposal to include USCDI v3 data elements was unclear and requested ONC clarify whether a Health IT Module must support these data elements so external DSI solutions can be integrated. One commenter expressed concern that the proposal for the data to be expressed in the standards in § 170.213 was unclear and recommended including USCDI data elements individually within the criterion for clarity on which elements would be required.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support and feedback received during the public comment period, and we have finalized several proposals based on such feedback. We thank the commenter for expressing their concern regarding our proposals to include the USCDI v3. We did not propose to establish requirements for specific interventions to be supported, only that Health IT Modules certified to § 170.315(b)(11) be capable of supporting interventions that use those listed data elements (88 FR 23783). The criterion at § 170.315(a)(9)(ii)(B)(
                        <E T="03">1</E>
                        ) listed many of the same types of information, such as medications for example, but the criterion at § 170.315(a)(9) did so without specifying a standard. As the result of our finalizing references to the standards in § 170.213, we have provided clarity and better alignment with other certification criteria in the Program. We appreciate the suggestion that we work with SDOs and coordinate listening sessions with DSI developers. We will take these suggestions under consideration for future work, including potential future workshops, listening sessions, and advisory group task forces.
                    </P>
                    <P>
                        We have finalized § 170.315(b)(11)(ii)(A) with a minor modification to remove “(
                        <E T="03">e.g.,</E>
                         system administrator)” from that provision (which is also in existing regulation text at § 170.315(a)(9)(ii)(A)), as this example is unnecessary. We have also finalized the list of data elements proposed at § 170.315(b)(11)(ii)(B)(
                        <E T="03">1</E>
                        ) with the following modifications in consideration of comments. We have moved the list from proposed § 170.315(b)(11)(ii)(B)(
                        <E T="03">1</E>
                        ) and finalized the list at § 170.315(b)(11)(iii)(A)(
                        <E T="03">1</E>
                        ) and finalized the list as proposed. We have finalized the list of data elements in § 170.315(b)(11)(iii)(A)(
                        <E T="03">1</E>
                        ) because they establish a scope for evidence-based DSIs that must be supported by Health IT Modules certified to § 170.315(b)(11) as well as scope the evidence-based DSIs that are subject to requirements in § 170.315(b)(11)(v). Including the list in § 170.315(b)(11)(iii)(A)(
                        <E T="03">1</E>
                        ) is intended to make this connection clearer.
                    </P>
                    <P>
                        We note that elsewhere in this final rule we have finalized an expiration date in § 170.213 for USCDI v1 to occur on January 1, 2026. Consistent with the applicable dates for the versions of the 
                        <PRTPAGE P="1239"/>
                        USCDI in § 170.213, this means Health IT Modules certified to § 170.315(b)(11) need only support the listed data elements according to the USCDI v1 standard until this time. A Health IT Module certified to § 170.315(b)(11) may support the data elements according to the USCDI v3 standard adopted in § 170.213 as of the effective date of this final rule. On and after January 1, 2026, Health IT Modules certified to § 170.315(b)(11) must support those listed data elements according to the USCDI v3 standard consistent with § 170.213.
                    </P>
                    <P>
                        We have also finalized § 170.315(b)(11)(ii)(B)(
                        <E T="03">2</E>
                        ) as § 170.315(b)(11)(ii)(B) due to the corresponding shift of the list of evidence-based DSI-related data elements noted above. We did not propose any changes to § 170.315(b)(11)(ii)(B) in transposing the proposed regulatory text from the regulation text at § 170.315(a)(9)(ii)(B)(
                        <E T="03">2</E>
                        ), and we have finalized regulation text proposed at § 170.315(b)(11)(ii)(B)(
                        <E T="03">2</E>
                        ) using existing language found at § 170.315(a)(9)(ii)(B)(
                        <E T="03">2</E>
                        ) at § 170.315(b)(11)(ii)(B).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters generally expressed support for the proposal at § 170.315(b)(11)(ii)(C) to enable users to provide electronic feedback based on the information displayed through the DSI and applauded including human-readable display. However, there was concern among many commenters regarding the details of this proposal, including requirements that Health IT Modules must be able to export feedback data, including but not limited to the intervention, action taken, user feedback provided (if applicable), user, date, and location, so that the exported data can be associated with other relevant data. These concerns were generally related to how these requirements would impact usability, user interfaces, and ongoing innovation of decision support tools. Specific commenters noted that capturing the “action taken,” by a user would be particularly problematic and would degrade DSI to simple “yes/no” designs.
                    </P>
                    <P>Commenters suggested that we should limit the requirements to DSIs directly implemented by a developer of certified health IT and limit the requirements to interruptive alerts, because passive alerts cannot have associated user actions. Other commenters recommended the functionality to enable “feedback loops” be optional for users and that the requirement pertain to evidence-based DSIs exclusively.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments and thank commenters for their recommendations. We noted in the HTI-1 Proposed Rule that this is the second time we have proposed a functionality that would require a Health IT Module to enable a user to provide electronic feedback, also referred to as the capability to support “feedback loops,” on the performance of DSIs implemented at the point of care (88 FR 23783). We note that in our 2015 Edition Proposed Rule, we proposed to adopt new functionality that would require a Health IT Module certified to the CDS criterion in § 170.315(a)(9) to be able to record at least one action taken, and by whom it was taken, when a CDS intervention is provided to a user (
                        <E T="03">e.g.,</E>
                         whether the user viewed, accepted, declined, ignored, overrode, provided a rationale or explanation for the action taken, took some other type of action not listed here, or otherwise commented on the CDS intervention) (80 FR 16821). At the time, many commenters stated that current systems already provided a wide range of functionality to enable providers to document decisions concerning CDS interventions and that such functionality was unnecessary to support providers participating in the EHR Incentive Programs (80 FR 62622). However, subsequent research over the last seven years indicates that “feedback loop” functionality is not widely available across Health IT Modules certified to the CDS criterion in § 170.315(a)(9), but that such functionality could be useful (88 FR 23784).
                    </P>
                    <P>We appreciate the comments asking us to clarify to which DSI types our proposals would pertain. We agree with commenters who indicated that feedback loop functionality would be most appropriate for evidence-based DSIs. We have finalized § 170.315(b)(11)(ii)(C) to make clear that this functionality would only be required to apply to evidence-based decision support interventions. We decline to limit this functionality to interruptive alerts only, but we believe that interruptive alerts can be improved if user feedback data is applied to make such interruptions more meaningful.</P>
                    <P>While we are receptive to concerns regarding usability, we do not believe that the finalized requirements to enable a user to provide electronic feedback on evidence-based DSIs constrain or hinder usability or would lead to CDS degradation because this electronic feedback data can be gathered in ways that are non-disruptive to users and we believe our requirements are sufficiently flexible to enable a user to provide feedback in a manner appropriate to their workflow. Furthermore, we note that while Health IT Modules must support the capability at § 170.315(b)(11)(ii)(C) in order to demonstrate conformance to the certification criterion, a user still needs to choose to implement such functionality. A user would not be required to provide feedback; rather, the capability to enable a user to provide electronic feedback is what must be included within the Health IT Module.</P>
                    <P>We clarify that only evidence-based DSIs that are actively presented to users in clinical workflow to enhance, inform, or influence decision-making related to the care a patient receives must be supported by the “feedback loop” functionality described in § 170.315(b)(11)(ii)(C). We believe that scoping the requirement for feedback loops to these kinds of evidence-based DSIs would be both appropriate to the goal of enabling ongoing quality improvement of DSIs, as discussed on 88 FR 23784-23785, and feasible for Health IT Modules to support. We also clarify that a Health IT Module must be able to make available feedback data to a limited set of identified users for export in a computable format. This clarifies that while the Health IT Module must enable any user to provide electronic feedback, the Health IT Module is not required to export this feedback data to any user; rather, such an export of feedback data must be available to a limited set of identified users.</P>
                    <P>As it relates to concerns regarding the “action taken,” requirement, we note that the action taken will be specific to the intended use of the evidence-based DSI. Actions could include whether the user viewed, accepted, declined, ignored, overrode, or modified the DSI in some way. At this time, we decline to require an enumerated list of “actions taken” be supported. We believe that developers of certified health IT and their customers are better positioned to determine the range of actions that are appropriate as part of feedback data.</P>
                    <HD SOURCE="HD3">iii. Evidence-Based Decision Support Interventions</HD>
                    <P>
                        In the HTI-1 Proposed Rule, we proposed at 88 FR 23784 to establish “evidence-based decision support interventions” at § 170.315(b)(11)(iii), with a minor revision to current requirements that are part of the CDS criterion in § 170.315(a)(9)(iii). We explained that this proposal would replace the current construct in § 170.315(a)(9)(iii), which states a Health IT Module must enable evidence-based decision support interventions “based on each one and at least one combination of” the data referenced in paragraphs 
                        <PRTPAGE P="1240"/>
                        § 170.315(a)(9)(ii)(B)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) through (
                        <E T="03">vi</E>
                        ). We proposed that Health IT Modules supporting evidence-based DSIs must have the ability to support “any,” meaning all, of the revised data referenced in paragraphs of proposed § 170.315(b)(11)(ii)(B)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) through (
                        <E T="03">viii</E>
                        ). We noted this proposal would broaden the scope of data elements that Health IT Modules must support when enabling evidence-based DSIs to include 15 data elements expressed by the standards in § 170.213, including USCDI v3, which we proposed to adopt in § 170.213(b) elsewhere in the HTI-1 Proposed Rule. The HTI-1 Proposed Rule did not prescribe the intended use of the evidence-based DSI. Rather, the proposed subparagraph at § 170.315(b)(11)(iii), in combination with the data referenced in § 170.315(b)(11)(ii)(B)(
                        <E T="03">1</E>
                        ), represented the scope of evidence-based DSIs and scope of data that Health IT Modules certified to § 170.315(b)(11) should enable for purposes of certification under our Program.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters were generally evenly split on their support for the proposal to establish “evidence-based decision support interventions,” with a minor revision to current requirements that are part of the CDS criterion in § 170.315(a)(9)(iii), with those in support noting that it would ensure that decision support systems are founded on the latest scientific research and clinical guidelines and assist healthcare professionals in making informed and effective choices that are supported by robust evidence. One commenter appreciated that we differentiated between predictive and evidence-based DSIs to support decision-making. One commenter noted that they believed it is critical that ONC account for the needs of clinical guideline developers so that undue burdens are not placed on the guideline development process as DSI tools are developed and implemented in part based on clinical guidelines.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments. We have finalized § 170.315(b)(11)(iii) with accompanying modifications and clarifications. As articulated in more detail in subsequent responses, we clarify that evidence-based DSIs, for purposes of requirements in § 170.315(b)(11), are limited to only those DSIs that are actively presented to users in clinical workflow to enhance, inform, or influence decision-making related to the care a patient receives and that do not meet the definition for Predictive Decision Support Intervention at § 170.102. Actively presented stands in contrast to decision support that initiates an action without a user's knowledge or occurs outside a user's normal workflow. We believe this clarification will help interested parties differentiate between evidence-based DSIs and Predictive DSIs and delineate which requirements in § 170.315(b)(11) pertain to these DSI types. We also note that some data elements in § 170.315(b)(11)(iii)(A) are not part of USCDI v1 and are only in USCDI v3. For the time period before the expiration date of USCDI v1, Health IT Modules are not required to support evidence-based DSIs that are based solely on data elements included in USCDI v3. However, beginning January 1, 2026, Health IT Modules must support DSIs based on all—meaning each—USCDI v3 data element listed in § 170.315(b)(11)(iii)(A).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters not in support of the proposal expressed concern that the definition of 
                        <E T="03">evidence-based DSI</E>
                         was too broad and would encompass a large number of baseline functionality and capabilities within an EHR including passive and active alerts, order sets, care plans and protocols, simple rules and calculations, references ranges, age and weight based dosing and reminders for preventative care. Commenters sought more clarity related to how evidence-based and Predictive DSIs were defined and should be supported. Specifically, commenters noted concerns related to consistently determining what types of functionalities qualify as an evidence-based DSI, a Predictive DSI, or neither. Commenters also noted that EHRs support a vast number of financial and reimbursement rules to support medical necessity and reimbursement. The commenters recommended that the definition of evidence-based DSI align with the current § 170.315(a)(9) definition of clinical decision support and that the § 170.315(a)(9) certification criterion remain unchanged until future rulemaking can more clearly define the criterion and specific priority use cases beyond clinical.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their concerns and understand there is substantial confusion regarding the scope of what constitutes an evidence-based DSI as well as corresponding requirements for evidence-based DSIs in § 170.315(b)(11). In the HTI-1 Proposed Rule we included background information indicating that the initial CDS criterion, established in 2010, required that a Health IT Module could: (1) implement rules, “according to specialty or clinical priorities;” (2) “automatically and electronically generate and indicate in real-time, alerts and care suggestions based upon clinical decision support rules and evidence grade;” and (3) track, record, and generate reports on the number of alerts responded to by a user (75 FR 2046).” (88 FR 23774). Since this time, the CDS criterion has remained agnostic to use case, except for drug-drug and drug-allergy contraindication checking, requiring Health IT Modules to enable the use of a variety of tools based on a specified set of data, including problems, medications, demographics, and laboratory data. While this framing has ensured that users have access to a broad range of tools, for a wide array of purposes, related to decision support through Health IT Modules certified to the CDS criterion, we now believe some clarity is needed to refine the scope of evidence-based DSIs for the purposes of requirements in § 170.315(b)(11).
                    </P>
                    <P>
                        We noted in the HTI-1 Proposed Rule that we were not establishing requirements for specific interventions to be supported, only that Health IT Modules certified to § 170.315(b)(11) be capable of supporting interventions based on specified data (as proposed in § 170.315(b)(11)(ii)(B)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) through (
                        <E T="03">viii</E>
                        ) (88 FR 23783)). We also noted in the HTI-1 Proposed Rule that the term “intervention,” 
                        <SU>88</SU>
                        <FTREF/>
                         is specific to “an intervention occurring within a workstream, including but not limited to alerts, order sets, flowsheets, dashboards, patient lists, documentation forms, relevant data presentations, protocol or pathway support, reference information or guidance, and reminder messages,” (88 FR 23786).
                    </P>
                    <FTNT>
                        <P>
                            <SU>88</SU>
                             The ONC Program's use of the term “intervention” is different from “clinical intervention” as defined under FDA regulation that includes a range of regulated products, such as a medication or medical device. We note that there may be a software-as-a-medical device (SaMD) that is considered a “clinical intervention” and subject to FDA authority.
                        </P>
                    </FTNT>
                    <P>
                        Given the confusion conveyed through comments received from many interested parties regarding the scope of what decision support is considered evidence-based decision support, we clarify that for purposes of requirements in § 170.315(b)(11), evidence-based DSIs are limited to only those DSIs that are actively presented to users in clinical workflow to enhance, inform, or influence decision-making related to the care a patient receives and that do not meet the definition for Predictive DSI at § 170.102.
                        <SU>89</SU>
                        <FTREF/>
                         In the context of Program 
                        <PRTPAGE P="1241"/>
                        requirements, this means that if a developer of certified health IT with a Health IT Module certified to § 170.315(b)(11) enables a user to select an evidence-based DSI that is actively presented in clinical workflow to enhance, inform, or influence decision-making related to the care a patient receives that evidence-based DSI would be subject to the requirements that apply to evidence-based DSIs within § 170.315(b)(11). We note that if the DSI in question meets the definition of Predictive DSI at § 170.102, then requirements that apply to those types of interventions within § 170.315(b)(11) would be applicable. Additionally, we clarify that “actively presented,” is inclusive of, but not limited to, “interruptive alerts,” and we clarify that “related to the care a patient receives,” would include use cases related to direct patient care as well as use cases that impact care a patient receives. For example, a decision support rule that recommends a follow-up appointment within 12 weeks according to United States Preventive Services Taskforce (USPSTF) recommendations would be considered an evidence-based DSI for purposes of Program requirements. These clarifications stand in contrast to back-end systems rules that are not presented to users and are not related to care an individual patient receives, such as those used for resource management or back-end logic that may support an organization's business rules but are not part of a user's workflow. Such rules and tools would not be considered an evidence-based DSI for the purposes of this certification criterion.
                    </P>
                    <FTNT>
                        <P>
                            <SU>89</SU>
                             We note that this clarification is aligned with FDA's Clinical Decision Support Software Guidance, specifically the software functionalities described under Criterion 3, which refers to condition-, disease-, or patient-specific recommendations to a health care professional to enhance, inform, or influence a health care decision. Note that we reference the FDA CDS Guidance only to clarify the scope of which kinds 
                            <PRTPAGE/>
                            of evidence-based DSIs are subject to applicable requirements in § 170.315(b)(11). See 
                            <E T="03">https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software.</E>
                        </P>
                    </FTNT>
                    <P>
                        Beyond this clarification, we have finalized § 170.315(b)(11)(iii) by changing the title of the paragraph from proposed “
                        <E T="03">Evidence-based decision support interventions,</E>
                        ” to “
                        <E T="03">Decision support intervention selection</E>
                        ” and included explicit instruction for Health IT Modules to enable a limited set of identified users to select (
                        <E T="03">i.e.,</E>
                         activate) decision support interventions (in addition to drug-drug and drug-allergy contraindication checking) that are evidence-based DSIs and Predictive DSIs. We have finalized the same requirement for all DSI types recognized in the Program, be they evidence-based DSIs or Predictive DSIs, because the technical capability to enable a user to select (
                        <E T="03">i.e.,</E>
                         activate) is the same regardless of the type of DSI being activated. As described in more detail below, Program requirements to enable a user to select a DSI is contingent only on the data elements in § 170.315(b)(11)(iii)(A) (for evidence-based DSIs) and § 170.213 (for Predictive DSIs) and supportive of various use cases.
                    </P>
                    <P>As discussed in more detail in the section III.C.5.v. “Predictive Decision Support Interventions, Attestation for Predictive Decision Support Interventions,” we did not adopt the Predictive DSI attestation statement proposed at § 170.315(b)(11)(v) in this final rule and we have narrowed the overall scope of technologies impacted by finalized requirements in § 170.315(b)(11). Given these changes, certain adjustments to the certification criterion were necessary to simplify, clarify, and align technical requirements that could be shared between evidence-based DSIs and Predictive DSIs. We believe these adjustments directly respond to commenter confusion and help reduce the technical updates that developers will need to complete in response to final requirements in § 170.315(b)(11) as they will be able to build on and extend existing capabilities to support Predictive DSIs. This is particularly true with respect to the capability expressed at final § 170.315(b)(11)(iii). Further, the alignment of evidence-based DSI and Predictive DSI capabilities will help provide for a consistent experience for those users identified to select DSIs pursuant to final § 170.315(b)(11)(iii).</P>
                    <P>While we specifically discussed evidenced-based DSIs in the HTI-1 Proposed Rule (88 FR 23784) with respect to proposed § 170.315(b)(11)(iii), we did not (aside from the paragraph title) expressly limit the scope of the proposed regulation text to evidenced-based DSIs—instead focusing on “electronic decision support interventions.” Moreover, at 88 FR 23783, we noted that requirements proposed at § 170.315(b)(11)(ii) for DSI configuration “would pertain to both evidence-based DSIs and predictive DSIs that are enabled by or interfaced with a certified health IT Module, including any predictive DSIs that are developed by users of the certified Health IT Model.” We have addressed these ambiguities in finalized regulation text at § 170.315(b)(11)(iii) and appreciate the comments that sought more clarity related to the shared uses expected for certification for evidence-based and Predictive DSIs.</P>
                    <P>We note that the capability in § 170.315(b)(11)(iii) is consistent with the historic and current expectation for evidence-based DSIs in § 170.315(a)(9)(iii) and we reiterate that this capability does not require a developer of certified health IT with a Health IT Module certified to § 170.315(b)(11) to author, develop, or otherwise support a specific evidence-based DSI or Predictive DSI.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested that ONC reconsider including Unique Device Identifier(s) for a Patient's Implanted Devices as a required element, or alternatively recognize that any DSI around Unique Device Identifier(s) is likely to only use certain elements of the Unique Device Identifier, not the full Unique Device Identifier—particularly the Device Identifier—and suggested that adoption as a required element for support via evidence-based DSIs is unnecessary at this stage.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment. We noted in the HTI-1 Proposed Rule that we believed that data regarding a patient's procedures and whether a patient has an implantable medical device, as indicated by a unique device identifier (UDI), can play a significant role in contemporary DSIs (88 FR 23783). As a result, we proposed to require that Health IT Modules would support data from the Procedures data class and the Unique Device Identifier(s) for a Patient's Implantable Device(s) data class as an input to DSIs. The addition of UDI complements medications and proposed procedures as an important focal point for various decision support interventions, including those related to MRIs, post-implant clinical care, among other care scenarios (88 FR 23783). We note that under this requirement, a Health IT Module would be required to enable an evidence-based DSI that included a UDI as expressed in the standards in § 170.213, and we clarify this requirement is affirmed regardless of whether the full UDI is part of the intervention or a component of the full UDI, such as the device identifier or the production identifier. Both identifiers are required to be supported as a part of USCDI v1 (§ 170.213(a)) and v3 (§ 170.213(b)).
                        <SU>90</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>90</SU>
                             
                            <E T="03">https://www.healthit.gov/isa/uscdi-data-class/unique-device-identifiers-a-patients-implantable-devices#uscdi-v1.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested clarification on whether algorithms that use patient medical/demographic information to provide patient-specific screening, counseling, and preventive recommendations by mapping to well-known and established authorities are considered evidence-based DSI unless there is a “predicted value.” The commenter questioned if scenarios where the algorithm is calculating a risk 
                        <PRTPAGE P="1242"/>
                        value based on a pre-defined deterministic clinical guideline are included.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the opportunity to clarify this point. We note that to be considered a Predictive DSI, a function or technology must meet all parts of the definition in § 170.102. Namely, it must support decision-making based on algorithms or models that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis. Based on the information presented by this commenter, we do not believe a risk score based on a deterministic clinical guideline would be considered a Predictive DSI. Rather, this would be considered an evidence-based DSI. However, we note that whether a technology meets the definition of Predictive DSI is fact based, and this response should not be understood as determinative.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter noted that for non-predictive CDS certified to existing ONC standards, the new transparency requirements related to patient demographics, social determinants of health, and health status assessments would be difficult to implement as such information is often not available to the CDS developer and recommended that ONC not require this for certified CDS but encourage it when such information is available.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment and we note that our requirements for evidence-based DSIs related to source attributes is substantially unchanged from the existing requirements. We describe in more detail our final policy for source attributes in the section “vi. Source Attributes.” However, we will require that users can review whether and which patient demographics, social determinants of health, and health status assessments data are used as part of an evidence-based DSI.
                    </P>
                    <HD SOURCE="HD3">iv. Linked Referential CDS</HD>
                    <P>
                        At 88 FR 23784, we proposed to replicate what is currently in § 170.315(a)(9)(iv) as § 170.315(b)(11)(iv) with a modification to reference the criterion in § 170.315(b)(11) wherever the current reference is to § 170.315(a)(9). We welcomed comment regarding the functionalities and standards listed in § 170.315(a)(9)(iv), the HL7 Context Aware Knowledge Retrieval Application (“Infobutton”) standards, including whether linked referential CDS were commonly used with, or without, the named standards in § 170.315(a)(9)(iv)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ) and whether we should continue to require use of these standards.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters were in support of removing the linked referential CDS provisions from the scope of the criterion, noting that it emphasizes the shift in focus to AI and machine learning-based DSI technology and removes a requirement that has been of little value for health care providers. In particular, commenters were supportive of removing the HL7 Context Aware Knowledge Retrieval Application (“Infobutton”) standards from the scope of the criterion, noting that removal is appropriate because there is low utilization for this standard, there is significant expansion of the proposed criterion in the areas of evidence-based and Predictive DSI, it would help streamline the certification process, and that customers perceive it as lacking value to clinical workflow in favor of traditional evidence-based CDS interventions. However, one commenter strongly supported retention of the “Infobutton” standard for linked referential DSIs but did not provide a rationale.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their recommendations. We agree with commenters that “infobuttons,” while helpful and useful in some contexts, no longer need to be mandated as part of the revised criterion at § 170.315(b)(11). We also note that the “infobutton” standard has not been updated for several years (since 2014). As part of an effort to streamline and update the historic criterion at § 170.315(a)(9), we have finalized § 170.315(b)(11) without proposed paragraph (b)(11)(iv) Linked referential DSI and associated subparagraphs. We anticipate that “infobuttons” and other linked referential DSIs will continue to be used where they provide value without a requirement in the Program. We believe that removal of this requirement as part of the revised certification criteria at § 170.315(b)(11) will reduce overall burden and focus requirements on evidence-based and Predictive DSIs.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter was supportive of our proposal to include “linked referential DSIs” in the Program, noting that it has the advantage of equipping health care providers with comprehensive and up-to-date resources, thus empowering them to make well-informed decisions by drawing upon a wealth of knowledge and clinical expertise, ultimately improving patient outcomes.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the commenter's support for the requirement. However, we have finalized § 170.315(b)(11) without requiring “Linked referential DSIs.” We reiterate that in circumstances where linked referential DSIs and “infobuttons” are providing value, nothing in this final rule would inhibit their use. Furthermore, nothing in this final rule should be used to inhibit the use of diagnostic and therapeutic reference information or any associated bibliographic information that is part of the linked referential DSI.
                    </P>
                    <HD SOURCE="HD3">v. Predictive Decision Support Interventions</HD>
                    <P>We proposed at 88 FR 23784 to reference a new intervention type, “predictive decision support intervention,” in § 170.315(b)(11)(v), and we proposed a corresponding definition in § 170.102. We also proposed in § 170.315(b)(11)(v)(A) that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) attest “yes” or “no” as to whether their Health IT Module enables or interfaces with one or more Predictive DSIs based on any of the data expressed in the standards in § 170.213, including USCDI v3, which we also proposed at 88 FR 23746.</P>
                    <HD SOURCE="HD3">Definition of Predictive Decision Support Intervention</HD>
                    <P>
                        We proposed at 88 FR 23784-23785 a definition of “predictive decision support intervention,” (again hereafter referenced as Predictive DSI) in § 170.102 to mean “technology intended to support decision-making based on algorithms or models that derive relationships from training or example data and then are used to produce an output or outputs related to, but not limited to, prediction, classification, recommendation, evaluation, or analysis.” We explained that such Predictive DSIs are based on the use of predictive model(s), and that “model” refers to a quantitative method, system, or approach that applies statistical, economic, bioinformatic, mathematical, or other techniques (
                        <E T="03">e.g.,</E>
                         algorithm or equations) to process input data into quantitative estimates. We also discussed our use of the phrase “intended to support decision-making” to be interpreted broadly and to encompass technologies that require users' interpretation and action to implement as well as those that initiate patient management without user action and require action to contest. We also noted that our use of Predictive DSI was not tied to who developed it, the level of risk or degree to which the Predictive DSI informs or drives treatment, is relied upon by the user, relates to time sensitive action, or whether the Predictive DSI is augmentative or 
                        <PRTPAGE P="1243"/>
                        autonomous.
                        <SU>91</SU>
                        <FTREF/>
                         We differentiated Predictive DSIs as those that support decision-making by learning or deriving relationships to produce an output, rather than those that rely on pre-defined rules based on expert consensus, such as computable clinical guidelines, to support decision-making.
                    </P>
                    <FTNT>
                        <P>
                            <SU>91</SU>
                             
                            <E T="03">See generally</E>
                             IMDRF | Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations: 
                            <E T="03">https://www.imdrf.org/documents/software-medical-device-possible-framework-risk-categorization-and-corresponding-considerations.</E>
                        </P>
                        <P>
                            See AMA | CPT® Appendix S: Artificial Intelligence Taxonomy for Medical Services and Procedures: 
                            <E T="03">https://www.ama-assn.org/system/files/cpt-appendix-s.pdf</E>
                             for definitions of “augmentative” and “autonomous”; ANSI/CTA Standard, The Use of Artificial Intelligence in Health Care: Trustworthiness ANSI/CTA-2090: https://shop.cta.tech/collections/standards/products/the-use-of-artificial-intelligence-in-healthcare-trustworthiness-cta-2090?_ga=2.195226476.1947214965.1652722036-709349392.1645133306.
                        </P>
                    </FTNT>
                    <P>We noted in the HTI-1 Proposed Rule that our definition of Predictive DSI was intended to cover a wide variety of techniques from algebraic equations to machine learning and natural language processing (NLP) (88 FR 23785). We mentioned the Acute Physiology and Chronic Health Evaluation IV (APACHE IV) model, which predicts in-hospital mortality for patients in intensive care units and was initially trained and validated with data from 45 hospitals, including over 100,000 individuals in 2006 (88 FR 23785). We also mentioned that models designed to estimate risk of a first Atherosclerotic Cardiovascular Disease, trained and validated on pooled cohorts of large studies as examples of common and in-scope models for our definition of Predictive DSI. We also noted that more complex models, for instance ones developed by combining multiple algorithms or deep neural networks trained and validated on over ten thousand individuals, that can be applied to patients in operational contexts would meet the proposed definition. So too would our definition include models that were adaptive, online or unlocked, which continue to adapt when exposed to new data, as well as those that are locked to the relationships learned in training data.</P>
                    <P>
                        As proposed in § 170.102, the definition of Predictive DSI would not include simulation models that use modeler-provided parameters rather than training data or unsupervised machine learning techniques that do not predict an unknown value (
                        <E T="03">i.e.,</E>
                         are not labeled) (88 FR 23786). For instance, the use of an unsupervised learning model within decision support would not meet our definition of Predictive DSI, nor would the use of developer-supplied parameters to simulate operating-room usage and develop an effective scheduling strategy. We refer readers to 88 FR 23784-23786 for the discussion on the definition of Predictive DSI.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters were mixed in their support for the proposed definition of Predictive DSI, with those in support noting that it provides broad flexibility, comprehensively encompasses AI, and accurately highlights its distinction from any other potential sources of decision support interventions that do not involve modeling. Some commenters expressed support particularly for including complex predictive models leveraging machine learning in the proposed definition, noting that this recognition serves as a necessary step to combat bias and promote equity amid the growing number and increased use of AI tools.
                    </P>
                    <P>
                        While many commenters broadly supported the intent and goals of the proposed definition for Predictive DSI, other commenters expressed concern that the proposed definition was too broad and should be narrowed in several ways to provide clarity on the scope of technologies covered to prevent burden on health IT developers and health care providers. Other commenters noted that a broad definition of Predictive DSI creates confusion for what technology must be scoped for certification. Notably, many commenters suggested revising the definition to clarify that Predictive DSI means technology intended to support 
                        <E T="03">clinical</E>
                         or 
                        <E T="03">medical</E>
                         decision-making to ensure organizational and administrative decision making are excluded from the definition to limit the documentation requirements to demonstrate compliance and limit the number of citations in the system to alleviate user burden. For instance, one commenter suggested that ONC add the term “clinical” so that Predictive DSI means “Predictive decision support intervention means technology intended to support clinical decision-making based on algorithms or models that derive relationships from training or example data and then are used to produce an output or outputs related to, but not limited to, prediction, classification, recommendation, evaluation, or analysis.” Commenters recommended that the definition be limited to high risk DSIs, and that it should exclude certain health care providers, such as those that develop their own DSI and do not make it commercially available. Commenters also requested that we reconsider the proposals to apply a more limited scope that centers on functionality that necessitates the granular transparency of source attributes and feedback capabilities for end-users that ONC proposed.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support from those commenters that said our definition comprehensively encompasses AI, and accurately highlighted the definition's distinction from any other potential sources of decision support interventions that do not involve modeling. We sought to establish a definition that was both broad and appropriate. Consistent with our rationale to move from CDS to DSI in Program nomenclature, we sought to establish a definition that encompassed the broad forms that algorithm and model-based decision support interventions can take and for which transparency regarding the performance of that model would benefit users, and would help users determine whether the technology they are using is fair, appropriate, valid, effective, and safe. We also sought to establish a definition that did not include a range of simple alerts and functions that would not benefit from the sorts of transparency our requirements would portend. However, we note there are many recent examples 
                        <E T="51">92 93 94</E>
                        <FTREF/>
                         where the task of delineating between those predictive algorithms and models can have unintended consequences.
                    </P>
                    <FTNT>
                        <P>
                            <SU>92</SU>
                             Samorani M., Harris S.L., Blount L.G., et al (2021) Overbooked and Overlooked: Machine Learning and Racial Bias in Medical Appointment Scheduling. Manufacturing &amp; Service Operations Management 24(6):2825-2842. 
                            <E T="03">https://doi.org/10.1287/msom.2021.0999.</E>
                        </P>
                        <P>
                            <SU>93</SU>
                             Vyas D.A., Eisenstein L.G., Jones D.S. Hidden in Plain Sight—Reconsidering the Use of Race Correction in Clinical Algorithms. Aug. 2020. N Engl J Med 2020; 383:874-882. DOI: 10.1056/NEJMms2004740.
                        </P>
                        <P>
                            <SU>94</SU>
                             Ziad Obermeyer et al., Dissecting racial bias in an algorithm used to manage the health of populations. Science 366, 447-453 (2019). DOI:10. 1126/science.aax2342.
                        </P>
                    </FTNT>
                    <P>
                        We thank commenters for their critiques of our definition. Many commenters said that our definition was too broad, and a small minority of these commenters offered specific suggestions on how to reduce the scope of our definition. We thank those commenters, especially. We understand that many algorithms not directly supporting medical decision making can nevertheless impact the delivery of healthcare (
                        <E T="03">e.g.,</E>
                         algorithms supporting scheduling or the provision of supplies), and so have not sought to limit the definition to models specifically informing medical decision making. Overall, we found that many other commenters did not consider our definition for Predictive DSI as a whole; rather, these commenters chose to isolate certain phrases or aspects of the 
                        <PRTPAGE P="1244"/>
                        definition to question its scope and its applicability to specific use cases. As stated, our intention with the definition of Predictive DSI is to be expansive beyond the traditional role of CDS, yet appropriate to the dynamic technology environment that Predictive DSIs may be applied. Toward these two intentions, we noted in the HTI-1 Proposed Rule that we differentiate Predictive DSIs as those that support decision-making by learning or deriving relationships to produce an output, rather than those that rely on pre-defined rules to support decision-making (88 FR 23785). Taken alongside the rest of the definition, this distinction is intended to preclude the vast number of alerts or reminders that are either based on consensus clinical guidelines or bespoke business processes and organizational policies that may or may not be based on any guideline.
                    </P>
                    <P>We also noted in the HTI-1 Proposed Rule that our definition is not tied to the level of risk (88 FR 23785) and our certification criterion for CDS was established to ensure that Health IT Modules support broad categories of CDS while being agnostic toward the intended use of the CDS beyond drug-drug and drug-allergy interaction checks (88 FR 23774). We did not propose to alter that construct in our proposals. However, we are sensitive to defining Predictive DSIs in a way that makes clear which technologies are in scope for § 170.315(b)(11).</P>
                    <P>We also decline to limit the definition to a specific source or developer of the intervention, although additional facets of the final policy define the applicable scope of § 170.315(b)(11).</P>
                    <P>
                        We have finalized our proposed definition for Predictive DSI with modification. Specifically, we have finalized the definition in § 170.102 as follows: “Predictive decision support intervention or Predictive DSI means technology that supports decision-making based on algorithms or models that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis.” We note that this version of the definition is not markedly different from the definition we proposed, but we intend it to be more exacting. Thus, the examples and discussion regarding scope in the HTI-1 Proposed Rule remain relevant to this definition (88 FR 23784-23786). To help interested parties better understand the scope of technologies included in this definition we reiterate the following: The development process whereby models under this definition “learn” relationships in training data and then are used to generate an unknown label or value (via prediction, classification, recommendation, evaluation, or analysis) that is based on the “learned” relationships is a fundamental differentiator from evidence-based DSIs. While we appreciate commenters' request to limit or constrain the scope of the Predictive DSI definition based on its intended purpose or use (
                        <E T="03">e.g.,</E>
                         clinical and medical versus administrative), level of risk (
                        <E T="03">e.g.,</E>
                         high versus low), and entity or party that developed the technology (
                        <E T="03">e.g.,</E>
                         health care provider that self-develops versus technology company that sells Predictive DSIs), we do not believe such an approach would be appropriate. We believe that the transparency requirements within this criterion are appropriate to all Predictive DSIs used within the context of certified health IT, given the potential of these Predictive DSIs to impact the delivery of healthcare at vast scale. We believe that constraining the definition of Predictive DSI by intended purposes, level of risk, or developing entity would create multiple layers of complexity and lead to different requirements for technology that may have qualities that pertain to one or more of these dimensions or exist along a spectrum of these concepts. We believe that a broad and consistently applied definition will improve the likelihood of achieving our stated goals for transparency and trustworthiness.
                    </P>
                    <P>We note that the definition of Predictive DSI is aligned with and within the scope of the definition of Artificial Intelligence at 15 U.S.C. 9401(3), as used in E.O. 14110, Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence (88 FR 75191). Predictive DSIs perceive environments through the use of training data; abstract perceptions into models as they learn relationships in that data; and produce an output, often for an individual, through inference based on those learned relationships. We further note that evidence-based DSI likely represents another form of Artificial Intelligence, though that form is fundamentally based on rules-based models.</P>
                    <P>We also clarify that the exclusion of unsupervised learning models discussed at 88 FR 23786 was intended to focus on models trained in data without labels. This exclusion reflected our understanding that it is not feasible to produce descriptions for many of the source attributes we are requiring for Predictive DSI. For example, unsupervised models are generally based on data without labels, which often generate measures of similarity or closeness of observations rather than a predicted value. In these instances, assessing the accuracy, validity and fairness of a prediction would be difficult, if not impossible, because the outcome is not specified. The exclusion of unsupervised learning models is embedded in the definition because the definition focuses on “relationships in training data,” which generally refers to the relationship between some set of data (sometimes referred to as inputs, features, or predictors) and an outcome or label (such as a diagnosis or the next word in a string). In contrast, unsupervised learning models rely more generally on patterns in data. We further clarified this exclusion in the HTI-1 Proposed Rule at 88 FR 23786 and maintain the exclusion in the final definition.</P>
                    <P>
                        These unsupervised models contrast with LLMs and other forms of generative AI, which often leverage self-supervised learning wherein the data itself provides a label (
                        <E T="03">e.g.,</E>
                         the next word in a string of text) and the model returns a predicted value of that label as output, in which case the accuracy, validity and fairness of a prediction can readily be assessed (although additional use-case specific evaluation may also be beneficial). Self-supervised learning models would therefore generally be included within the definition of Predictive DSI. We also note that LLMs and other forms of generative AI often use a combination of unsupervised, self-supervised, supervised and reinforcement learning, and those that include a component of supervised learning, including semi-supervised approaches, would likely meet the definition of Predictive DSI.
                    </P>
                    <P>
                        Finally, we understood that models that solely rely on unsupervised learning techniques are not widely deployed in healthcare today.
                        <SU>95</SU>
                        <FTREF/>
                         We will continue to monitor development of methodologies and applications of unsupervised learning to health-related use cases and may consider future rulemaking for these models as the field develops.
                    </P>
                    <FTNT>
                        <P>
                            <SU>95</SU>
                             Michael Matheny, et al., 
                            <E T="03">Artificial intelligence in health care: the hope, the hype, the promise, the peril,</E>
                             Washington, DC: National Academy of Medicine (2019).
                        </P>
                        <P>
                            <E T="03">Artificial Intelligence in Health Care: Benefits and Challenges of Technologies to Augment Patient Care,</E>
                             (Nov. 2020), 
                            <E T="03">https://www.gao.gov/products/gao-21-7sp.</E>
                             Deo, Rahul C. “Machine learning in medicine.” 
                            <E T="03">Circulation</E>
                             132.20 (2015): 1920-1930.
                        </P>
                        <P>
                            American Hospital Association. “Surveying the AI Health Care Landscape” 2019. 
                            <E T="03">https://www.aha.org/system/files/media/file/2019/10/Market_Insights_AI-Landscape.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concern about consistency, duplication, and redundant requirements across various federal 
                        <PRTPAGE P="1245"/>
                        programs. Commenters recommended that ONC tailor the scope of the proposed term Predictive DSI, and the proposed definition at § 170.102, to exclude FDA-authorized AI and machine learning medical devices to mitigate their concerns mentioned above. Specifically, one commenter recommended tailoring the Predictive DSI requirements to explicitly exclude tools that are regulated medical devices, to exclude third-party tools that qualify as non-device per the statutory exemption for CDS software, and, to apply only to technology developed by vendors of certified Health IT Modules to avoid unnecessary burdens on regulated device manufacturers. Commenters noted that our proposal for Predictive DSI could implicate CDS software that falls within FDA regulated medical devices which may have already been cleared, approved, or otherwise authorized for marketing within the United States.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the concerns expressed by these commenters, which is why we worked closely with the FDA on development of our proposals in § 170.315(b)(11). This collaboration included consultation with the FDA on the inclusion or exclusion of devices within FDA's authority in the definition of Predictive DSI. Specifically, we sought alignment with the FDA's recent Clinical Decision Support Guidance for Industry (CDS Guidance), finalized in September 2022,
                        <SU>96</SU>
                        <FTREF/>
                         and we note that our requirements in § 170.315(b)(11) are complementary to FDA's Content of Premarket Submissions for Device Software Functions guidance, finalized in June 2023.
                        <SU>97</SU>
                        <FTREF/>
                         This high degree of coordination will reduce burden on device manufacturers by establishing the potential that a device manufacturer that also develops a Predictive DSI can fulfill two separate federal agency's requirements with substantially similar or the same information.
                    </P>
                    <FTNT>
                        <P>
                            <SU>96</SU>
                             See 
                            <E T="03">https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>97</SU>
                             See 
                            <E T="03">https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions.</E>
                        </P>
                    </FTNT>
                    <P>
                        We noted in the HTI-1 Proposed Rule that our authority to regulate developers of certified health IT under the Program is separate and distinct from other federal agencies' regulatory authorities focused on the same or similar entities and technology (88 FR 23811).
                        <SU>98</SU>
                        <FTREF/>
                         For example, the safety and effectiveness of a software function, including clinical decision support or other kinds of decision support interventions, is within the purview of FDA regulatory oversight, if such software functionality meets the definition of a “device.” 
                        <SU>99</SU>
                        <FTREF/>
                         In the area of predictive technology, ONC and FDA support a harmonized and complementary approach, independent of the platform on which the technology operates, in accordance with our existing intersecting regulatory oversight. We also noted in the HTI-1 Proposed Rule that questions of whether DSIs enabled by or interfaced with certified health IT are subject to FDA regulations, under the Federal Food, Drug, &amp; Cosmetic Act, or are used by entities subject to the HIPAA Rules, are separate and distinct from the question of whether a developer or a particular technology is subject to regulatory oversight by our Program, to which our proposals pertain (88 FR 23811).
                    </P>
                    <FTNT>
                        <P>
                            <SU>98</SU>
                             See U.S. Dept of Health &amp; Human Servs., Office for Civil Rights, Notice of Proposed Rulemaking, Nondiscrimination in Health Programs and Activities, 87 FR 47824, 47880 (Aug. 4, 2022), 
                            <E T="03">https://www.federalregister.gov/documents/2022/08/04/2022-16217/nondiscrimination-in-health-programs-and-activities</E>
                             (prohibiting discrimination on the basis of race, color, national origin (including limited English proficiency), sex (including sexual orientation and gender identity), age, or disability in certain health programs or activities 
                            <E T="03">through the use of clinical algorithms in their decision-making</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>99</SU>
                             A device, as defined in section 201(h) of the FD&amp;C Act, can include an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is, among other criteria, intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease in man. The term “device” does not include software functions excluded pursuant to section 520(o) of the FD&amp;C Act. For more information about determining whether a software function is potentially the focus of the FDA's oversight, please visit the FDA's Digital Health Policy Navigator Tool: 
                            <E T="03">https://www.fda.gov/medical-devices/digital-health-center-excellence/digital-health-policy-navigator.</E>
                        </P>
                    </FTNT>
                    <P>We also anticipate that in a scenario where a Device CDS (this is a CDS with software functions) has been cleared, approved, or otherwise authorized for marketing by the FDA, this device's manufacturer will have ready access to much of the information necessary for it to comply with requirements in § 170.315(b)(11) as a developer of certified health IT.</P>
                    <P>We appreciate the suggestions to exclude from our definition for Predictive DSI software that are regulated medical devices and to exclude third-party software that qualify as non-device software functions per the statutory exemption for CDS software. However, we decline to include any exclusionary criteria in our definition for Predictive DSI, such as exclusions for specific types of functions or specific types of Predictive DSI developers because the finalized definition is appropriate to reflect the wide variety of predictive tools that impact and intersect with the delivery of healthcare. Also, whether or not a given technology or tool is a Predictive DSI should be consistent regardless of the developer of the tool. We also note—as stated above and previously in the HTI-1 Proposed Rule—that the FDA and ONC have separate and distinct authorities and regulate for separate and distinct purposes with separate and distinct policy objectives (88 FR 23811). Moreover, we stress the benefits that such alignment and coordination brings to users. Because of our requirements for source attributes in § 170.315(b)(11), users of both CDS with device software functions and Non-Device CDS will have easy access to important information at the point-of-care.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested we clarify the proposed definition of Predictive DSI by providing examples of use cases to show the application of the policy. One commenter recommended that ONC include a clear standard or definition as to which entities the HTI-1 Proposed Rule applied to, and which applications and tools are in scope for Predictive DSIs.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We understand commenters' desire to have ONC assess whether specific algorithms, models, and technologies would meet the definition for Predictive DSI. in § 170.102. Rather than make specific assessments to these commenters' questions, we provide the following examples of technologies that would likely meet our definition for Predictive DSI and examples of technologies that would likely not meet our definition for Predictive DSI:
                    </P>
                    <P>
                        1. Models that predict whether a given image contains a malignant tumor or that predict patient reported pain based on an image, trained based on relationships observed in large data sets often using neural networks, would likely be considered Predictive DSIs.
                        <SU>100</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>100</SU>
                             Pierson, Emma, et al. “An algorithmic approach to reducing unexplained pain disparities in underserved populations.” 
                            <E T="03">Nature Medicine</E>
                             27.1 (2021): 136-140. Hosny, Ahmed, et al. “Artificial intelligence in radiology.” 
                            <E T="03">Nature Reviews Cancer</E>
                             18.8 (2018): 500-510.
                        </P>
                    </FTNT>
                    <P>2. Models that pre-selected or highlighted a default order from an order set based on relationships in training data indicating that order was most likely to be selected would likely be considered Predictive DSIs.</P>
                    <P>
                        3. Models that predict risk of sepsis, readmission (
                        <E T="03">e.g.,</E>
                         LACE+), estimated glomerular filtration rate (eGFR), or risk of suicide attempt, which have been trained based on relationships observed in large data sets, often using logistic 
                        <PRTPAGE P="1246"/>
                        regression and machine learning techniques, and are used to support decision making, would likely be considered Predictive DSIs.
                        <SU>101</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>101</SU>
                             van Walraven, Carl, Jenna Wong, and Alan J. Forster. “LACE+ index: extension of a validated index to predict early death or urgent readmission after hospital discharge using administrative data.” 
                            <E T="03">Open Medicine</E>
                             6.3 (2012): e80.
                        </P>
                        <P>
                            Levey, Andrew S., et al. “A more accurate method to estimate glomerular filtration rate from serum creatinine: a new prediction equation.” 
                            <E T="03">Annals of internal medicine</E>
                             130.6 (1999): 461-470.
                        </P>
                        <P>
                            Walsh, Colin G., Jessica D. Ribeiro, and Joseph C. Franklin. “Predicting risk of suicide attempts over time through machine learning.” 
                            <E T="03">Clinical Psychological Science</E>
                             5.3 (2017): 457-469.
                        </P>
                        <P>
                            Fleuren, Lucas M., et al. “Machine learning for the prediction of sepsis: a systematic review and meta-analysis of diagnostic test accuracy.” 
                            <E T="03">Intensive care medicine</E>
                             46 (2020): 383-400.
                        </P>
                    </FTNT>
                    <P>
                        4. Indices and classification systems developed by expert consensus rather than in empirical data, such as the SOFA index and NYHA Heart Failure classification, would likely not be considered Predictive DSIs but are likely evidence-based DSI because the score is based on pre-defined rules and not relationships learned in training data.
                        <SU>102</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>102</SU>
                             Vincent, J -L., et al. “The SOFA (Sepsis-related Organ Failure Assessment) score to describe organ dysfunction/failure: On behalf of the Working Group on Sepsis-Related Problems of the European Society of Intensive Care Medicine (see contributors to the project in the appendix).” (1996): 707-710.
                        </P>
                    </FTNT>
                    <P>5. Models that generate clinical notes or draft clinical notes and that were trained based on relationships in large data sets of free text, including large language models, and support decision making about what to document in the clinical note, would likely be considered Predictive DSIs.</P>
                    <P>6. Models that use natural language processing to route secure messages, which were trained based on the relationship between message contents and the individual who responded to similar messages in the past would likely be considered Predictive DSIs.</P>
                    <P>7. Rules-based algorithms for routing secure messages based on the type of message, rather than relationships in training data, would likely not be considered Predictive DSIs.</P>
                    <P>
                        8. Growth charts, for instance percentile calculations based on a lambda-mu-sigma transformation of similar age children's weights, with parameters learned in training data from a national sample of children, would likely not be considered Predictive DSIs because the underlying model is based on the distribution of a single variable (
                        <E T="03">e.g.,</E>
                         weight) rather than a prediction based on relationships between variables.
                    </P>
                    <P>9. A calculation for BMI would likely not be considered a Predictive DSI because the calculation (weight divided by height squared) is not based on relationships in training data.</P>
                    <P>10. Patient matching algorithms based on indices of similarities, rather than by relationships in training data where an outcome is known, would likely not be Predictive DSIs. Many of these technologies are most similar to unsupervised machine learning, which we described previously in this section and in the HTI-1 Proposed Rule at 88 FR 23786 as out of scope of the current definition of Predictive DSI.</P>
                    <P>11. Optical character recognition, used simply to make a PDF readable or searchable to end users, would likely not be considered Predictive DSI because it does not support decision-making.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters were generally mixed on our mention of LLMs and other generative AI as in scope for the proposed definition of Predictive DSI in the HTI-1 Proposed Rule. Some commenters in support agreed with our assessment that the use of predictive models, such as AI, invariably present model risk that can lead to patient harm, bias, widening health disparities, discrimination, inefficient resource allocation decisions, or ill-informed clinical decision-making. Commenters stated LLMs and generative AI tools could pose risks if they are not deployed appropriately and monitored carefully and viewed our proposals as a necessary step to combat bias and promote equity amid the growing number and increased use of AI tools.
                    </P>
                    <P>Other commenters expressed concern that LLMs, such as ChatGPT, would be covered in the proposed Predictive DSI definition, noting the definition could sweep in developers of general-purpose AI applications that enable or interface with Health IT Modules. One commenter noted that these models are fundamentally different than other Predictive DSI models, thus including these models in the same category as Predictive DSIs would be an inaccurate classification. Commenters were concerned that including LLMs could potentially limit their effective application in non-clinical aspects of healthcare software intended to help users save time and organizations save money and urged ONC to revise the definition so that developers of general-purpose AI applications are not obligated by the proposed requirements and instead that applications be evaluated within the context of a specific use case.</P>
                    <P>
                        <E T="03">Response.</E>
                         In the HTI-1 Proposed Rule, we were explicit in describing the scope of our Predictive DSI definition to include large language models, or LLMs, and other forms of generative AI that meet the definition of Predictive DSI. We do not believe that LLMs should be excluded from our definition for Predictive DSI if the LLMs are used to support decision-making, nor do we believe that LLMs are complete “black-boxes” about which no information can be made available to users that would be valuable. We agree with commenters that LLMs could pose a risk if they are not deployed appropriately. We believe that the source attribute- and risk management-related requirements in this rule could help to decrease the likelihood that a model is inappropriately deployed in a Health IT Module in a way that exacerbates bias or poses other risks. We note that we have finalized a fundamentally limited the scope in § 170.315(b)(11) to focus on transparency capabilities and instances where Predictive DSIs (such as LLMs or other generative AI) are supplied by a developer of certified health IT—and not generally on LLMs or generative AI that may be used in the healthcare ecosystem. If, as part of its Health IT Module, a health IT developer supplies an LLM or other generative AI that meets the definition of Predictive DSI, the finalized policy in § 170.315(b)(11) requires the health IT developer's Health IT Module certified to § 170.315(b)(11) to enable access to complete and up-to-date plain language descriptions of source attribute information related to that Predictive DSI. Our finalized policy also requires Health IT Modules certified to § 170.315(b)(11) to, at a minimum, have the technical capability for users and 
                        <E T="03">other parties</E>
                         to populate the source attributes listed in § 170.315(b)(11)(iv) themselves. We agree with commenters that LLMs should be evaluated within the context of specific use cases and believe that the scope of this final rule will not limit the effective application of LLMs.
                    </P>
                    <P>
                        Regarding commenters' concerns about LLMs being fundamentally different and requiring different kinds of source attributes that are more fit for transparency purposes, we note that our requirements for source attributes represent a minimum “floor,” and developers of certified health IT are encouraged to provide additional source attributes to users as appropriate. We also describe in more detail in subsequent responses that we have finalized a requirement for Health IT Modules to enable a limited set of identified users to record, change, and access additional source attribute information not specified in § 170.315(b)(11)(iv)(B) of this final rule. This will enable users to identify source 
                        <PRTPAGE P="1247"/>
                        attributes and record, change, and access those source attributes based on local validation and enable users to access emerging transparency measures specific to emerging Predictive DSI types, such as those based on LLMs.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern with the proposed definition including the term “derive relationships from training or example data,” stating that it is overly broad and unclear as to what would be considered in scope, such as whether general system improvements learned from user behavior would fall into this definition. The commenter also expressed concern with our preamble description that “Predictive models are those that have `learned' relationships from a training or historic data source, generally using some form of statistical or machine learning approach” stating that it is unclear whether commonly used predictions (
                        <E T="03">e.g.,</E>
                         LACE+ for readmission or a SOFA score) 
                        <SU>103</SU>
                        <FTREF/>
                         are included in the definition of Predictive DSI. The commenter requested that the definition should be clarified to focus only on models that are generated from machine learning techniques and for the types of clinical predictions that are not commonly used in medical practice and clarified to focus on a prediction of an unknown or future clinical event.
                    </P>
                    <FTNT>
                        <P>
                            <SU>103</SU>
                             Vincent, J.L., et al. “The SOFA (Sepsis-related Organ Failure Assessment) score to describe organ dysfunction/failure: On behalf of the Working Group on Sepsis-Related Problems of the European Society of Intensive Care Medicine (see contributors to the project in the appendix).” (1996): 707-710.
                        </P>
                        <P>van Walraven, Carl, Jenna Wong, and Alan J. Forster. “LACE+ index: extension of a validated index to predict early death or urgent readmission after hospital discharge using administrative data.” Open Medicine 6.3 (2012): e80.</P>
                    </FTNT>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment and the questions. We note that “derive relationships from training data” is only a part of the overall definition we have finalized. If a technology is used to make “general system improvements” based on training data that consists of “user behavior,” it may meet the definition of a Predictive DSI in § 170.102 if it derived relationships (for instance, correlations) from that training data and then produced an output that results in prediction, classification, recommendation, evaluation, or analysis used to support decision-making. “General system improvements” based on other analysis, such as tracking the time required to perform a task, would likely not meet the definition because that technology does not “derive relationships.” If “general system improvements learned from user behavior,” were the outputs of the technology or the effect of the technology, but that output was not used to support decision-making or was not a prediction, classification, recommendation, evaluation or analysis, then this technology likely would not meet our finalized definition.
                    </P>
                    <P>We noted above in examples that the LACE+ model for readmission would likely meet the definition of Predictive DSI at § 170.102 and because the SOFA score was defined by expert consensus, rather than training data, this would not likely meet the definition of Predictive DSI at § 170.102. We note that in our finalized definition, we have removed “or example” and now only refer to “training data,” for clarity and because we do not believe there is an appreciable or impactful difference between training and example data. We respectfully decline to include any exclusionary criteria in our definition for Predictive DSI, including exclusions for specific types of functions or specific types of Predictive DSI developers.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters recommended that we revise the definition to take a tiered approach to DSI requirements based on the type and level of meaningful risk to patients associated with the AI systems, suggesting that we should focus on “high-risk” DSIs, remarking that it would help alleviate public confusion and suggesting that this approach would better meet the intent of addressing the risks associated with DSI. One commenter recommended that Predictive DSI should not apply to consumer-facing devices and low risk tools, noting that the public interest would not be served by imposing regulatory compliance obligations on low-risk Predictive DSI use cases—even when applied in a clinical context. For example, Predictive DSI tools used for non-clinical purposes (
                        <E T="03">e.g.,</E>
                         EHR integrations for administrative notes and billing) do not present the sorts of risks that the HTI-1 Proposed Rule is intended to address. Along with clarifying that low-risk Predictive DSI tools are exempt, the commenter suggested that ONC should also issue guidance clarifying the types of proposed uses that are considered “low-risk.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We noted in the HTI-1 Proposed Rule that our definition is not tied to the level of risk (88 FR 23785), and we decline to focus on “high-risk” DSIs. Doing so would diverge from established approaches within the CDS criterion. The certification criterion for CDS was established to ensure that Health IT Modules certified to the criterion support broad categories of CDS, including by making information about the CDS available for user review, while being agnostic toward the intended use of the CDS beyond drug-drug and drug-allergy interaction checks (88 FR 23774). We did not propose to alter that construct in our proposals, and we respectfully decline to do so in this final rule. We do not agree with commenters that a focus on “high-risk” DSIs would alleviate public confusion because defining and determining levels of risk for Predictive DSIs that, in some cases indirectly, impact the healthcare of millions of individuals is complex and requires consideration of numerous factors. Instead, the information required for Predictive DSI will be beneficial for all Predictive DSI supplied by developers of certified health IT.
                    </P>
                    <P>
                        We also decline to include any exclusionary criteria in our definition for Predictive DSI, including exclusions for specific types of functions, such as consumer-facing tools or other “low risk” tools, or for specific types of Predictive DSI developers. We note that non-clinical Predictive DSIs and clinical Predictive DSIs that may be categorized as of relatively low risk have consequences for and impact the care individuals receive, and as we have noted elsewhere, demonstrably negative impacts beyond clinical safety have been well-documented in various studies and academic literature in recent years.
                        <SU>104</SU>
                        <FTREF/>
                         Together, we believe these factors warrant a broad and inclusive definition for Predictive DSI.
                    </P>
                    <FTNT>
                        <P>
                            <SU>104</SU>
                             Samorani M., Harris S.L., Blount L.G., et al (2021) Overbooked and Overlooked: Machine Learning and Racial Bias in Medical Appointment Scheduling. Manufacturing &amp; Service Operations Management 24(6):2825-2842. 
                            <E T="03">https://doi.org/10.1287/msom.2021.0999</E>
                            .
                        </P>
                        <P>
                            Vyas D.A., Eisenstein L.G., Jones D.S. Hidden in Plain Sight—Reconsidering the Use of Race Correction in Clinical Algorithms. Aug. 2020. 
                            <E T="03">N Engl J Med</E>
                             2020; 383:874-882. DOI: 10.1056/NEJMms2004740.
                        </P>
                        <P>
                            Ziad Obermeyer et al.,Dissecting racial bias in an algorithm used to manage the health of populations. 
                            <E T="03">Science</E>
                             366, 447-453 (2019). DOI: 10.1126/science.aax2342.
                        </P>
                        <P>
                            Delgado, Cynthia, et al. “A unifying approach for GFR estimation: recommendations of the NKF-ASN task force on reassessing the inclusion of race in diagnosing kidney disease.” 
                            <E T="03">Journal of the American Society of Nephrology</E>
                             32.12 (2021): 2994-3015.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters were concerned that due to the breadth of the definition, non-certified health IT would be included in the definition and believed the HTI-1 Proposed Rule should be limited to software that an EHR vendor submits for certification under the Program, noting that ONC's authority under the Program is limited to oversight of certified Health IT Modules and developers of certified health IT.
                        <PRTPAGE P="1248"/>
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We acknowledge that the definition of Predictive DSI itself may have broad applicability. As part of 45 CFR part 170, any application of the definition (and the related requirements in § 170.315(b)(11)) is limited to certified Health IT Modules and developers who develop them. We note that our definition does not depend on or reference the certification status of the entity that developed the technology that may or may not be considered a Predictive DSI. We established the definition to be agnostic to both use case and party that develops a Predictive DSI, and we and have not chosen to finalize a definition with any such caveats. As described elsewhere in the rule, and to address these and related commenters' concerns, we have focused the scope of Predictive DSIs to which our regulatory requirements apply to those supplied by the developer of certified health IT as part of its Health IT Module. We noted in the HTI-1 Proposed Rule that our authority to regulate developers of certified health IT and their Health IT Modules, ensuring that both conform to technical standards, certification criteria, implementation specifications, and adherence to Conditions and Maintenance of Certification requirements, is separate and distinct from other federal agencies' authorities to regulate for separate and distinct purposes with separate and distinct policy objectives that may be focused on the same or similar entities and technology (88 FR 23809-23810), that may pertain to the use of Predictive DSIs and technology, including AI and machine learning, in health and human services.
                        <SU>105</SU>
                        <FTREF/>
                         Outside of the Department of Health and Human Services, multiple federal agencies, within their unique authorities, are exploring policies pertaining AI and machine learning (88 FR 23810).
                        <SU>106</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>105</SU>
                             
                            <E T="03">See, e.g.,</E>
                             See U.S. Dept of Health &amp; Human Servs., Office for Civil Rights, Notice of Proposed Rulemaking, Nondiscrimination in Health Programs and Activities, 87 FR 47824, 47880 (Aug. 4, 2022), 
                            <E T="03">https://www.federalregister.gov/documents/2022/08/04/2022-16217/nondiscrimination-in-health-programs-and-activities</E>
                             (prohibiting discrimination on the basis of race, color, national origin (including limited English proficiency), sex (including sexual orientation and gender identity), age, or disability in certain health programs or activities 
                            <E T="03">through the use of clinical algorithms in their decision-making</E>
                            ).
                        </P>
                        <P>
                            CMS Medicare Advantage Program Final Rule (April 2023), 
                            <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>
                             (The rule clarified coverage criteria for basic benefits and the use of prior authorization, added continuity of care requirements, and required an annual review of utilization management tools).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>106</SU>
                             The Federal Trade Commission (FTC) has addressed AI repeatedly in its work through a combination of law enforcement, business education and policy initiatives. For example, numerous FTC orders have required companies to delete data and algorithms. 
                            <E T="03">See</E>
                             “Amazon/Alexa” case, 
                            <E T="03">https://www.ftc.gov/news-events/news/press-releases/2023/05/ftc-doj-charge-amazon-violating-childrens-privacy-law-keeping-kids-alexa-voice-recordings-forever</E>
                             (settling allegations that Amazon retained children's voice recordings indefinitely to feed its voice recognition algorithm in violation of a children's privacy law); “Ring” case, 
                            <E T="03">https://www.ftc.gov/news-events/news/press-releases/2023/05/ftc-says-ring-employees-illegally-surveilled-customers-failed-stop-hackers-taking-control-users</E>
                             (settling allegations that home security company allowed employees to access consumers' private videos); “Weight Watchers/Kurbo” case, 
                            <E T="03">https://www.justice.gov/opa/pr/weight-management-companies-kurbo-inc-and-ww-international-inc-agree-15-million-civil-penalty</E>
                             (settling allegations that weight loss app for use by children as young as eight collected their personal information without parental permission); “Everalbum” case, 
                            <E T="03">https://www.ftc.gov/legal-library/browse/cases-proceedings/192-3172-everalbum-inc-matter</E>
                             (settling allegations that the company deceived consumers about the use of facial recognition to analyze users' private images, including in connection with training FRT models); the “Mole Detective” case, 
                            <E T="03">https://www.ftc.gov/legal-library/browse/cases-proceedings/132-3210-new-consumer-solutions-llc-mole-detective</E>
                             (alleging deceptive conduct, where app developers claimed in advertisements that their consumer-facing app could determine based on photographs whether a mole was cancerous). In May 2023, the FTC issued a Policy Statement discussing the application of Section 5 of the FTC Act to the collection and use of biometric information (such as finger or hand prints, facial images or geometry, voice recordings, or genetic information), including the use of biometric information technologies developed using machine learning and similar techniques. Fed. Trade Comm'n, 
                            <E T="03">Policy Statement of the Federal Trade Commission on Biometric Information and Section 5 of the Federal Trade Commission Act</E>
                             (May 18, 2023), 
                            <E T="03">https://www.ftc.gov/system/files/ftc_gov/pdf/p225402biometricpolicystatement.pdf</E>
                            . In November 2023, the FTC filed a comment with the Copyright Office on Artificial Intelligence. 
                            <E T="03">See https://www.ftc.gov/legal-library/browse/advocacy-filings/comment-federal-trade-commission-artificial-intelligence-copyright</E>
                            . FTC staff guidance has warned companies about their obligation to use AI responsibly and identified concerns from consumers and about competition. 
                            <E T="03">See, e.g., Consumers Are Voicing Concerns About AI, https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2023/10/consumers-are-voicing-concerns-about-ai</E>
                             (October 3, 2023); 
                            <E T="03">Watching the detectives: Suspicious marketing claims for tools that spot AI-generated content</E>
                             (July 6, 2023); 
                            <E T="03">https://www.ftc.gov/business-guidance/blog/2023/07/watching-detectives-suspicious-marketing-claims-tools-spot-ai-generated-content; Generative AI Raises Competition Concerns, https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2023/06/generative-ai-raises-competition-concerns</E>
                             (June 29, 2023); 
                            <E T="03">Hey, Alexa! What are you doing with my data?</E>
                             (June 13, 2023), 
                            <E T="03">https://www.ftc.gov/business-guidance/blog/2023/06/hey-alexa-what-are-you-doing-my-data; The Luring Test: AI and the engineering of consumer trust</E>
                             (May 1, 2023), 
                            <E T="03">https://www.ftc.gov/business-guidance/blog/2023/05/luring-test-ai-engineering-consumer-trust; Chatbots, deepfakes, and voice clones: AI deception for sale</E>
                             (March 20, 2023), 
                            <E T="03">https://www.ftc.gov/business-guidance/blog/2023/03/chatbots-deepfakes-voice-clones-ai-deception-sale;</E>
                             and 
                            <E T="03">Keep your AI claims in check</E>
                             (February 27, 2023): 
                            <E T="03">Keep your AI claims in check</E>
                             (February 2, 2023), 
                            <E T="03">https://www.ftc.gov/business-guidance/blog/2023/02/keep-your-ai-claims-check; Aiming for truth, fairness, and equity in your company's use of AI</E>
                             (April 19, 2021), 
                            <E T="03">https://www.ftc.gov/business-guidance/blog/2021/04/aiming-truth-fairness-equity-your-companys-use-ai;</E>
                             Artificial Intelligence and Algorithms (Apr. 8, 2020), 
                            <E T="03">https://www.ftc.gov/news-events/blogs/business-blog/2020/04/using-artificial-intelligence-algorithms;</E>
                             The Commission has issued numerous reports related to algorithmic decision making. 
                            <E T="03">See</E>
                             FTC, Combatting Online Harms Through Innovation: A Report to Congress (June 2022), 
                            <E T="03">https://www.ftc.gov/reports/combatting-online-harms-through-innovation;</E>
                             FTC Report to Congress on Privacy and Security, September 2021, 
                            <E T="03">https://www.ftc.gov/system/files/documents/reports/ftc-report-congress-privacy-security/report_to_congress_on_privacy_and_data_security_2021.pdf;</E>
                             Fed. Trade Comm'n, Big Data: A Tool for Inclusion or Exclusion? (Jan. 2016), 
                            <E T="03">https://www.ftc.gov/system/files/documents/reports/big-data-tool-inclusion-or-exclusion-understanding-issues/160106big-data-rpt.pdf</E>
                            . For information on best practices to reduce bias and discrimination, 
                            <E T="03">see generally</E>
                             Rebecca Kelly Slaughter, Algorithms and Economic Justice, Yale J.L. &amp; Tech. (Aug. 2021), 
                            <E T="03">https://law.yale.edu/sites/default/files/area/center/isp/documents/algorithms_and_economic_justice_master_final.pdf</E>
                            . The agency has also held several public events focused on AI issues, including a workshop on generative AI, workshops on dark patterns and voice cloning, sessions on AI and algorithmic bias at PrivacyCon 2020 and 2021, a hearing on competition and consumer protection issues with algorithms and AI, a FinTech Forum on AI and blockchain, and an early forum on facial recognition technology (resulting in a 2012 staff report). See 
                            <E T="03">https://www.ftc.gov/news-events/events/2023/10/creative-economy-generative-ai; https://www.ftc.gov/news-events/events/2021/04/bringing-dark-patterns-light-ftc-workshop; https://www.ftc.gov/news-events/events-calendar/you-dont-say-ftc-workshop-voice-cloning-technologies; https://www.ftc.gov/news-events/events-calendar/privacycon-2021; https://www.ftc.gov/news-events/eventscalendar/privacycon-2020; https://www.ftc.gov/news-events/events-calendar/ftc-hearing-7-competition-consumerprotection-21st-century; https://www.ftc.gov/news-events/events-calendar/2017/03/fintech-forum-blockchainartificial-intelligence;</E>
                             and 
                            <E T="03">https://www.ftc.gov/news-events/events-calendar/2011/12/face-facts-forum-facialrecognition-technology</E>
                            .The Commission has issued an advanced notice of proposed rulemaking that poses questions about the harms to consumers that may result from commercial surveillance, including as related to algorithmic decision making. 
                            <E T="03">See</E>
                             FTC, Advance Notice of Proposed Rulemaking regarding Commercial Surveillance and Data Security (August 11, 2022), 
                            <E T="03">https://www.ftc.gov/legal-library/browse/federal-register-notices/commercial-surveillance-data-security-rulemaking</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters expressed concern that our proposed definition does not add clarity and offered other examples of definitions that ONC should consider. For example, one commenter recommended ONC use public definitions of AI and include a neural net component for an adopted definition of Predictive DSI. Another commenter suggested ONC narrow the definition of Predictive DSI to focus on outputs that are recommendations and to limit the definition by removing the proposed “. . . prediction, classification, evaluation or analysis” section of the proposed definition. One 
                        <PRTPAGE P="1249"/>
                        commenter urged ONC to survey the definitions of healthcare AI currently in use, including the American Medical Association Current Procedural Terminology (CPT®) Appendix S: AI taxonomy for medical services and procedures because it outlines the range of AI tools from those performing purely assistive functions to fully autonomous technologies.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments, and we are aware of the American Medical Association Current Procedural Terminology (CPT®) Appendix S: AI taxonomy for medical services and procedures. We think this taxonomy has value but decline to include specific purposes or kinds of machine learning in our Predictive DSI definition. We believe such constraints may unintentionally exclude relevant technology as it evolves and is applied to more use cases, humans interact with technology in more diverse ways, and societal views on the line between assistive and autonomous technologies shift. We, again, decline to modify our definition to exclude specific use cases, purpose of uses or intended uses and decline to modify our definition to include specific types of algorithms, such as neural networks, because we suspect the relevant algorithms will similarly evolve over time. We also decline to narrow the definition to exclude prediction, classification, evaluation and analysis because we believe that each of these types of output and use are of relevance in healthcare and can result from fundamentally similar technologies.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concern that the proposed definition included and implicated algorithms that are not directly tied to clinical workflows or capture large areas of software solutions used in certified EHR systems or types of interventions that are not conducive to source attributes or feedback gathering, specifically noting concerns with gathering feedback from passive clinical support. One commenter noted that the proposed definition could be interpreted to classify any list of patients, information form, or a comparison against a population average as Predictive DSI and recommended that ONC should remove the overly broad examples or clarify that the definition applies only when the predictive modifier applies.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments, and we acknowledge that our discussion regarding the term “intervention,” at 88 FR 23786, which included mention of “alerts, order sets, flowsheets, dashboards, patient lists, documentation forms, relevant data presentations, protocol or pathway support, reference information or guidance, and reminder messages,” was imperfectly placed. It was not our intention to intimate that each of these kinds of “interventions,” would always fall under the Predictive DSI definition but that each kind of intervention 
                        <E T="03">could</E>
                         be a Predictive DSI if they are driven by algorithms or models that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis. We believe that source attributes can be provided for a Predictive DSI that is used in operations, scheduling, payment, and other workflows and that there is value in doing so, for instance, for medical coders to evaluate the relevance of codes suggested by a Predictive DSI. We note that feedback gathering is limited to evidence-based decision support interventions, which have a more limited scope. We believe that our finalized definition and associated examples provide interested parties with better clarity on technology within the definition's scope.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concern that the proposed definition does not adequately distinguish Predictive DSI from evidence-based DSI, which they believed is also defined too broadly. Commenters provided examples they believed should be excluded from the definition, such as passive decision support, reminders for preventative care, industry standard growth charts, well established reference ranges, default selections in the system, suggested word completions when typing, or rules-based decision support. Several commenters recommended that DSIs should be limited to predictive, evidence-based medicine support interventions impacting clinical choice, and solutions supporting fact-based administrative functions, such as scheduling appointments or bed availability, should be carved out.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have provided a set of examples, discussed above, along with our finalized definition in § 170.102 of Predictive DSI as meaning technology that supports decision-making based on algorithms or models that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis. We also have clarified the scope of evidence-based DSIs, for purposes of requirements in § 170.315(b)(11), as being limited to only those DSIs that are actively presented to users in clinical workflow to enhance, inform, or influence decision-making related to the care a patient receives and that do not meet the definition for Predictive DSI at § 170.102. We decline to further limit the scope of the Predictive DSI definition, especially for administrative functions, which would likely benefit from the transparency our requirements would provide. We note that even appointment scheduling and block scheduling predictive models have been demonstrated to be of insufficient quality, causing harm to patients.
                        <SU>107</SU>
                        <FTREF/>
                         We believe that greater transparency on the quality of these models could have avoided harm to patients by users interpreting predictions more judiciously or choosing not to use the model, or by motivating developers to retrain the models.
                    </P>
                    <FTNT>
                        <P>
                            <SU>107</SU>
                             Samorani M., Harris S.L., Blount L.G., et al (2021) Overbooked and Overlooked: Machine Learning and Racial Bias in Medical Appointment Scheduling. Manufacturing &amp; Service Operations Management 24(6):2825-2842. 
                            <E T="03">https://doi.org/10.1287/msom.2021.0999</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters recommended that ONC limit the definition to exclude health care providers that have developed their own tools for internal use regardless of whether they are enabled by or interface with the EHR the provider uses from the proposed regulatory requirements. Commenters remarked that the distinction between health care providers and EHR vendors offering DSI services through certified health IT products is important as providers have greater understanding and experience with self-developed DSI tools they use internally and should not be subject to the same requirements as vendors offering DSI tools in certified health IT products for commercial use.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments. With regards to the definition of Predictive DSI, we did not propose and have not finalized a definition that is dependent on the entity or party developing the Predictive DSI. In other words, “who develops” a Predictive DSI is separate and distinct from how we define what a Predictive DSI is for the purpose of this regulation. Along those lines, while health care providers may develop Predictive DSIs (as we have defined), we have not excluded those provider-authored Predictive DSIs from meeting the regulatory definition. However, it is important for commenters to keep in mind that the definition is only one part of the Program's policy approach to Predictive DSIs. In response to comments that appeared to conflate “the who” and “the what” with respect to the definition, we clarify that a health 
                        <PRTPAGE P="1250"/>
                        care provider who self-develops a tool that meets our definition of Predictive DSI is not subject to the requirements in § 170.315(b)(11). We believe that `self-developed' tools, which may be developed by informaticians in a health system and then applied to individual patients by clinical users or others without knowledge of the development or evaluation process could benefit from the inclusion of transparency information guiding their use. And our finalized certification criterion in § 170.315(b)(11) would result in health care providers being equipped with the technological capabilities to deliver such transparency through Health IT Modules certified to § 170.315(b)(11). We describe requirements further below that Health IT Modules certified to § 170.315(b)(11) must support the technical capability for source attribute information to be accessed and modified by users as well as the limited contexts in which developers of certified health IT are required to populate those attributes. Specifically, as already noted, we have limited the scope of our transparency requirements for source attribute information to apply to Predictive DSIs that are supplied by the health IT developer as part of its Health IT Module.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter urged ONC to revise the proposed definition of Predictive DSI in a manner that specifically excludes laboratory results reported to a health care provider via a Health IT Module when such laboratory results are derived using an algorithm. The commenter noted their concern that the broad definition of Predictive DSI could cause Health IT developers to believe that a laboratory offering a test whose result is derived using an algorithm, and which is reported via an interfaced laboratory information system (LIS), must provide source attribute information about the test. The commenter also noted instrumentation result generation should not be considered covered by this DSI intervention rule, because laboratories' instrumentation remains under the auspices of standards established by the College of American Pathologists (CAP) and CLIA. One commenter expressly requested that we adopt an exception for radiologists in implementing DSI because they stated that DSI is not useful to that specialty and thus we should exempt them until the CMS Appropriate Use Criteria (AUC) program is available.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments. As noted above, we respectfully decline to include any exclusionary criteria in our definition for Predictive DSI, including exclusions for specific types of organizations that develop the Predictive DSI, exclusions for specific types of technology that may be considered a Predictive DSI, and exclusions for organizations or technology that may be subject to other federal requirements and authorities, like the Clinical Laboratory Improvement Amendments regulations,
                        <SU>108</SU>
                        <FTREF/>
                         the CMS Appropriate Use Criteria program,
                        <SU>109</SU>
                        <FTREF/>
                         or Medicare Advantage Program regulations related to utilization management.
                        <SU>110</SU>
                        <FTREF/>
                         Related to the lab example provided by the commenter, and reflective of our final policy, this example would generally 
                        <E T="03">not</E>
                         be within the scope of a developer of certified IT's accountability, unless the developer of certified health IT specifically supplied the laboratory Predictive DSI as part of its Health IT Module certified to § 170.315(b)(11). As indicated by the comment, the certified health IT would be receiving a lab result for an outside entity using instrumentation separate and distinct (not included as a part of the developer's certified health IT), even if that result was arrived at by the laboratory using a Predictive DSI.
                    </P>
                    <FTNT>
                        <P>
                            <SU>108</SU>
                             CLIA regulations include federal standards applicable to all U.S. facilities or sites that test human specimens for health assessment for to diagnose, prevent, or treat disease. CDC, in partnership with CMS and FDA, supports the CLIA program and clinical laboratory quality. For more information, see 
                            <E T="03">https://www.cdc.gov/clia/index.html</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>109</SU>
                             We note that CMS rescinded the regulations for the AUC program in the 2024 Physician Fee Schedule Final Rule (88 FR 79262). For more information about the program, see 
                            <E T="03">https://www.cms.gov/medicare/quality/appropriate-use-criteria-program.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>110</SU>
                             See, 
                            <E T="03">e.g.,</E>
                             CMS Medicare Advantage Program Final Rule (April 2023), 
                            <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>
                             (clarified coverage criteria for basic benefits and the use of prior authorization, added continuity of care requirements, and required an annual review of utilization management tools).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested clarification on whether patient matching algorithms are subject to the Predictive DSI definition, and thus included in the risk management and reporting requirements. The commenter was supportive of including patient matching algorithms under the proposed definition given that the models use example data to determine accuracy prior to implementation and produce an output stating which patient it believes matches to which record given the data it is presented with. The commenter observed that by being able to understand the matching algorithms themselves, the healthcare continuum can better react and hone its data capture practices ensuring the algorithms receive the best quality data to guarantee the best possible match given the algorithms' determinations. Relatedly, a second commenter requested clarification on whether an algorithm that assigns similarity scores without labels is not a Predictive DSI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment and refer readers to our finalized definition for Predictive DSI as technology that supports decision-making based on algorithms or models that derive relationships from training data and then produces an output that results in prediction, classification, recommendation, evaluation, or analysis. We are aware of a variety of methods to perform patient matching, including identifying whether specific fields are exact matches, or whether certain strings of text contain a high proportion of matching characters, and not all of them are based in relationships derived from training data.
                        <SU>111</SU>
                        <FTREF/>
                         Such patient matching methods would likely not be considered Predictive DSI if they were not based on relationships derived from training data. We further note that the exclusion of unsupervised machine learning approaches, which generally do not predict an unknown value but rather identify the similarity or closeness of data, described at 88 FR 23786, is likely to apply to some patient matching algorithms, which would also likely not be considered Predictive DSI. That same clarification would apply to other algorithms that generate a similarity or closeness score without labeled training data (for instance, patient phenotyping or search recommendations based on the similarity between search strings and document contents), which would likely not be considered Predictive DSI. Other patient matching algorithms, especially those leveraging a supervised learning approach, are likely to meet the definition of a Predictive DSI.
                    </P>
                    <FTNT>
                        <P>
                            <SU>111</SU>
                             Government Accountability Office. Health Information Technology: Approaches and Challenges to Electronically Matching Patients' Records across Providers. Jan 15, 2019.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         A different commenter was concerned with the proposed definition of Predictive DSI including the term “algorithm” because it suggested a more inclusive set of health IT than they believed was intended by legislative and regulatory scope, which they stated would create confusion in the marketplace. The commenter recommended refining DSI's definition by removing “algorithms” to limit scope specifically to decision support driven by models using example data. Some commenters recommended ONC shift the criterion back to a specific focus on 
                        <PRTPAGE P="1251"/>
                        clinical DSIs as an initial starting point for the revised criterion.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment and the concern. Our definition for Predictive DSI includes technology that supports decision-making based on both models and algorithms that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis. We understand that not all interested parties share the same conception of how an algorithm is related to a model or vice versa. Regardless, the existence of an algorithm in or as part of a technology is not, alone, determinative in meeting our definition for Predictive DSI. In addition to including an algorithm, a technology must also support decision-making based on the algorithm and that algorithm must derive, or learn, relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis. We also decline to limit the scope of our definition to focus on clinical uses as previously discussed in this section.
                    </P>
                    <HD SOURCE="HD3">Attestation for Predictive Decision Support Interventions</HD>
                    <P>In proposed § 170.315(b)(11)(v)(A), at 88 FR 23786, we proposed that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) attest “yes” or “no” to whether their Health IT Module enables or interfaces with Predictive DSIs based on any of the data expressed in the standards in § 170.213. This attestation requirement would have the effect of permitting developers of certified health IT to certify to § 170.315(b)(11) without requiring their Health IT Modules to enable or interface with Predictive DSIs. However, for those developers of certified health IT that attest “yes” as described in § 170.315(b)(11)(v)(A), we described in the HTI-1 Proposed Rule additional applicable requirements related to source attributes and IRM practices (88 FR 23786).</P>
                    <P>
                        We clarified that “enables” means that the developer of certified health IT has the technical capability to support a predictive model or DSI within the developer's Health IT Module. We clarified that applications developed by other parties and self-developed applications that are used within or as a part of a Health IT Module would mean that the Health IT Module is considered to “enable” Predictive DSIs. We provided an example, stating that if the calculations or processing for a Predictive DSI occur within the Health IT Module, either through a standalone application developed by an 
                        <E T="03">other party</E>
                         
                        <SU>112</SU>
                        <FTREF/>
                         or an application self-developed by a developer of certified health IT for use within a Health IT Module, we would consider this “enabling.” In contrast, we clarified that “interfaces with” means that the Health IT Module facilitates either (1) the launch of a predictive model or DSI or (2) the delivery of a predictive model or DSI output(s) to users when such a predictive model or DSI resides outside of the Health IT Module and provided examples. We noted that some organizations may use USCDI data exported or sourced from a certified Health IT Module to develop data-driven advanced analytics leveraging predictive models or technologies to provide insights for healthcare. We also noted that in such circumstances, our proposed requirements would only apply if the output of the predictive model subsequently interfaced with a Health IT Module. The proposed requirement would not establish requirements for predictive technologies that are not enabled or do not interface with a Health IT Module.
                    </P>
                    <FTNT>
                        <P>
                            <SU>112</SU>
                             Please note that “other party” is a term of art we described at 88 FR 23796. In this final rule, we have italicized 
                            <E T="03">other party</E>
                             and 
                            <E T="03">other parties</E>
                             to assist readers' understanding that we are using this term of art and not misspelling “another.”
                        </P>
                    </FTNT>
                    <P>
                        Finally, we clarified that 
                        <E T="03">other parties</E>
                         includes any party that develops a DSI, a model, or an algorithm that is used by a DSI and is not a developer of certified health IT (88 FR 23796). We said these other parties could include, but are not limited to: a customer of the developer of certified health IT, such as an individual health care provider, provider group, hospital, health system, academic medical center, or integrated delivery network; a third-party software developer, such as those that publish or sell medical content or literature used by a DSI; or researchers and data scientists, such as those who develop a model or algorithm that is used by a DSI.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters were generally supportive of the proposal to enable Health IT Modules to be certified to § 170.315(b)(11) without the health IT developer being obligated to provide Predictive DSIs to their customers by having developers of certified health IT attest “yes” or “no” to whether their Health IT Module enables or interfaces with Predictive DSIs based on any of the data expressed in the standards in § 170.213. Commenters requested that we reflect that health IT developers would not be compelled to provide (or author) Predictive DSIs due to the attestation statements adopted in this provision.
                    </P>
                    <P>Notwithstanding the general support, many commenters did not support the “enables or interfaces with,” construct associated with the attestation proposed in § 170.315(b)(11)(v)(A). Many commenters noted that the “enables or interfaces with,” scope was a vague, ambiguous, and problematic phrase when applied to the proposed definition for Predictive DSI. Commenters, specifically health IT developers, were concerned that it would be hard to comply with the “enables or interfaces with” scope on which conditional requirements for source attributes and IRM practice requirements would rely. Commenters requested that we further define and narrow the scope of “enables or interfaces with,” and commenters stated that ONC should clearly define the scope of activities or technologies to which the related requirements for source attributes and IRM practices apply. For example, some commenters suggested that source attribute and IRM practice requirements should only apply in specific situations, such as when entities have contracts specifically covering the enablement and use of such technologies. Commenters also expressed substantive concerns that the phrase “enables or interfaces with” would require health IT developers to meet the transparency requirements for all third-party apps that customers utilize via § 170.315(g)(10) technology. They also stated that it would be difficult for developers to know when these third-party apps “enable or interfaced with” their Health IT Module and difficult to require third parties to provide source attributes information, particularly when there is no contractual relationship between the health IT developer and those third parties.</P>
                    <P>
                        Taken together and as we looked at the substance of comments comprehensively, we noticed that commenters described circumstances that would otherwise make the original intent behind the attestation proposal moot. Instead of enabling a health IT developer that did not provide or author Predictive DSIs to meet the attestation for proposed § 170.315(b)(11)(v) by attesting “no” regarding their support for Predictive DSIs, many developers appeared to convey that they would need to attest “yes” because of their understanding of the proposed scope for “enable or interface with.” This was because they interpreted our proposal for “enable or interface with” to include their accountability for customer actions associated with Predictive DSIs, which would not necessarily be known at the 
                        <PRTPAGE P="1252"/>
                        time of certification and, as a result, the developer of certified health IT would have to err on the side of expecting that one of their customers would enable or interface their Health IT Module with a Predictive DSI. In short, we understood from commenter feedback that developers of certified health IT could not reasonably validate whether customers were using Health IT Modules to enable or interface with Predictive DSIs.
                    </P>
                    <P>
                        On the whole, commenters contended that our proposal included ambiguities and challenges related to implementation, knowledge, and ongoing compliance. The latter of which would be the most difficult for developers of certified health IT based on what we had proposed. For example, if under our proposal, a developer had attested “no” and then months later a single customer had “enabled or interfaced with” an 
                        <E T="03">other party</E>
                         Predictive DSI with the developer's Health IT Module (certified to § 170.315(b)(11)), it was unclear whether the developer would need to reengage its ONC-ACB to change its certificate for § 170.315(b)(11) and attest “yes” and take on the additional compliance requirements. Comments also made clear that we should seek to minimize and separate how independent customer actions and decisions associated with Predictive DSIs interplay with conditional compliance requirements for developers of certified health IT under the Program.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' feedback on the attestation proposal, its construction within the criterion at § 170.315(b)(11), and how to make it more implementable. In summary, the intent behind the proposed attestation statement and its associated framing was to establish a conditional approach whereby developers of certified health IT certifying to § 170.315(b)(11) would still be able to get certified to § 170.315(b)(11) even if their Health IT Module did not enable or interface with a Predictive DSI. We had hoped that this would relieve specific regulatory burdens for developers of certified health IT that had no intention to enable or interface with a Predictive DSI. However, as commenters pointed out, because of the broad scope of “enable or interfaced with” even those developers that could have plausibly attested “no” may still have felt it necessary to attest “yes” when seeking certification. Despite not knowing of customers using Health IT Modules to enable or interface with a Predictive DSI, these developers of certified health IT would need to attest “yes” as soon as single customer used their certified Health IT Module to enable or interface with a Predictive DSI. We interpreted these developer compliance concerns, about whether they would know if a customer had enabled or interfaced a Predictive DSI with their Health IT Module, as an important implementation issue and necessary to address as part of this final rule.
                    </P>
                    <P>
                        In consideration of these and similar comments, we have not adopted the attestation statement we proposed in § 170.315(b)(11)(v). Given the circumstances and concerns described by commenters, we have concluded that accurate attestations, relieved burden, and clear (initial and ongoing) compliance would not have been accomplished as proposed. Rather than adopt an attestation statement, we have finalized minimal, uniform requirements for all Health IT Modules certified to § 170.315(b)(11) while also maintaining a construction that enables a developer of certified health IT to certify a Health IT Module to § 170.315(b)(11) without being obligated to author, develop, or otherwise directly provide Predictive DSIs to their customers. In response to comments, we believe this synthesized approach provides developers of certified health IT with clear policy and layered compliance requirements that are specifically within the scope of the Program and that of the developer's control (
                        <E T="03">i.e.,</E>
                         a customer's action will not create any corresponding compliance impact on a developer's § 170.315(b)(11) compliance).
                    </P>
                    <P>As described throughout this section, we have removed “enabled or interfaced with” and replaced it with “supplied by.” The final rule's scope places the knowledge, decision, and ongoing compliance associated with including a Predictive DSI solely within the control of a developer of certified health IT. While the use of “supplied by” is a different configuration nexus than the proposed attestation statement that used “enables or interfaces with,” this approach similarly addresses our intent to only apply additional Predictive DSI related stewardship responsibilities to health IT developers who supply Predictive DSIs as part of their Health IT Module. The paragraphs that follow illustrate by way of final certification criterion requirements some of the changes we have made in response to comments associated with the certification criterion's focus on Predictive DSI's “supplied by” the health IT developer and the corresponding effect of not finalizing the attestation. We believe the finalized requirements provide much more certainty for health IT developers while still addressing our overall policy goal for § 170.315(b)(11)—to provide as part of the Program greater transparency associated with DSIs, particularly Predictive DSIs and their ability to be FAVES.</P>
                    <P>
                        First, we have adopted requirements in § 170.315(b)(11)(iii), described previously in this final rule, that enables a limited set of identified users to select (
                        <E T="03">i.e.,</E>
                         activate) electronic DSIs that are evidence-based in (b)(11)(iii)(A) and predictive in (b)(11)(iii)(B). We believe that this uniform requirement to enable the selection of a Predictive DSI represents a minimal level of effort beyond, and a slight modification to, what developers of certified health IT would have had to do if we had finalized the “no,” attestation. Such developers of certified health IT would have had to enable selection of evidence-based DSIs and supported source attribute fields for evidence-based DSIs. As stated previously, enabling the selection of Predictive DSIs would likely be operationalized through the same technical means as enabling selection of an evidence-based DSI. Additionally, and in acknowledgement of our proposed rule discussion that requirements for DSI configuration in § 170.315(b)(11)(ii) applied to both evidence-based DSIs and Predictive DSIs (88 FR 23783), we believe that Health IT Modules certified to § 170.315(b)(11) would have baseline expectations to support both user configuration of Predictive DSIs and user selection of Predictive DSIs. Finally, we believe that software development of fields to support source attributes (in § 170.315(b)(11)(v)(B)) for Predictive DSIs would likely not be substantially more burdensome than the work necessary to develop fields to support evidence-based DSI source attributes (in § 170.315(b)(11)(A)).
                    </P>
                    <P>
                        Second, the finalization of § 170.315(b)(11) without an attestation statement but with uniform requirements for users to configure and have the technical capability to select both evidence-based and Predictive DSIs achieves a policy goal to ensure that users have equal technical capabilities to access, record, and change Predictive DSI source attributes in § 170.315(b)(11)(v)(B) for Predictive DSIs they self-develop and for Predictive DSIs they purchase from other parties, in addition to potential Predictive DSIs supplied by the users' developer of certified health IT. Under the proposed attestation statement with the enables or interfaces with configuration nexus, users of Health IT Modules that attested “no,” would have technical challenges to use self-
                        <PRTPAGE P="1253"/>
                        developed or 
                        <E T="03">other party-</E>
                        developed Predictive DSIs. This is because Predictive DSI-related source attribute fields (proposed in § 170.315(b)(11)(vi)(C)) and Predictive DSI-related capabilities to author and revise source attributes (proposed in § 170.315(b)(11)(vi)(E)) would not have been required for those “no attestation” Health IT Modules to support. We believe that as the market for Predictive DSIs grows, equivalent technical capabilities for users to access, record, and change source attributes in § 170.315(b)(11)(iv) across Health IT Modules certified to § 170.315(b)(11) will be vital to promote Predictive DSIs that are FAVES.
                    </P>
                    <P>Third, we have narrowed the focus of requirements related to providing IRM practices information on Predictive DSIs to those that are “supplied by the health IT developer as part of its Health IT Module.” This approach reduces the overall scope of technologies subject to final requirements in § 170.315(b)(11) while keeping the intent of the attestation statement we proposed. For instance, our finalized policy in § 170.315(b)(11)(vi) requires that for Predictive DSIs supplied by the developer of certified health IT as part of its Health IT Module the developer would have to address specific IRM practices associated with each Predictive DSI it supplies. As noted and similar to our intent with the “no” attestation proposal, based on the revised scope in this final rule, if a health IT developer does not supply any Predictive DSIs it will still be able to comply with § 170.315(b)(11) and will not have to meet, for example, IRM practice requirements in § 170.315(b)(11)(vi) because the health IT developer does not supply any Predictive DSIs as part of its Health IT Module. We note, however, if after certification to § 170.315(b)(11), a developer does begin to supply Predictive DSIs as part of its certified Health IT Module, it would need to comply with all applicable requirements in § 170.315(b)(11).</P>
                    <P>
                        We interpret “supplied by” to include interventions authored or developed by the health IT developer as well as interventions authored or developed by an 
                        <E T="03">other party</E>
                         that the health IT developer includes as part of its Health IT Module, such as stated in the comments “when entities have contracts specifically covering the enablement and use of such technologies.” The concept of “supplied by” means that the developer of certified health IT has taken on stewardship and accountability for that Predictive DSI for the purposes of the Health IT Module. We interpret “as part of its Health IT Module” to mean that the developer of certified health IT has explicitly offered or provided its customers the technical capability to use or support a Predictive DSI, regardless of whether the Predictive DSI was developed by the developer of certified health IT or by an 
                        <E T="03">other party.</E>
                    </P>
                    <P>
                        By way of example, “supplied by the health IT developer as part of its Health IT Module” would include the implementation of a publicly available predictive model, like LACE+,
                        <SU>113</SU>
                        <FTREF/>
                         if a developer of certified health IT includes this Predictive DSI as part of its product and it is part of what the developer offers its customers. As another example, “supplied by the health IT developer as part of its Health IT Module” would include incorporation of an 
                        <E T="03">other party's</E>
                         LLM, or other generative AI, that meets the definition of Predictive DSI and is part of what the developer offers its customers.
                    </P>
                    <FTNT>
                        <P>
                            <SU>113</SU>
                             van Walraven, Carl, Jenna Wong, and Alan J. Forster. “LACE+ index: extension of a validated index to predict early death or urgent readmission after hospital discharge using administrative data.” 
                            <E T="03">Open Medicine</E>
                             6.3 (2012): e80.
                        </P>
                    </FTNT>
                    <P>
                        From a conformance perspective, “supplied by the health IT developer as part of its Health IT Module” means that developers of certified health IT are not accountable for populating source attribute information for, or applying IRM practices, to Predictive DSIs in instances where their customers choose to deploy a self-developed Predictive DSI or an 
                        <E T="03">other party</E>
                        -developed Predictive DSI for use within their certified health IT. This is true even if the customer leverages data from the developer of certified health IT's Health IT Module and even if the output from an 
                        <E T="03">other party's</E>
                         Predictive DSI is delivered to or through a Health IT Module into a customer's clinical workflow.
                    </P>
                    <P>
                        We reiterate that 
                        <E T="03">other party</E>
                         means any party that develops a DSI, a model, or an algorithm that is used by a DSI, and is not the developer of certified health IT or a subsidiary of the developer of certified health IT. This is consistent with our discussion in the HTI-1 Proposed Rule on 88 FR 23796.
                        <SU>114</SU>
                        <FTREF/>
                         This description of 
                        <E T="03">other party</E>
                         in this final rule preamble specifically excludes a subsidiary of a developer of certified health IT. We intend for purposes of our requirements in § 170.315(b)(11) that a subsidiary of a developer of certified health IT that develops a Predictive DSI would be considered the same as if it were the developer of certified health IT, subjecting Predictive DSIs developed by a subsidiary to the same requirements as a Predictive DSI supplied by a developer of certified health IT as part of its Health IT Module.
                    </P>
                    <FTNT>
                        <P>
                            <SU>114</SU>
                             As noted in HTI-1 Proposed Rule, 
                            <E T="03">Other parties</E>
                             can include, but are not limited to: a customer of the developer of certified health IT, such as an individual health care provider, provider group, hospital, health system, academic medical center, or integrated delivery network; a third-party software developer, such as those that publish or sell medical content or literature used by a DSI; or researchers and data scientists, such as those who develop a model or algorithm that is used by a DSI (88 FR 23796).
                        </P>
                    </FTNT>
                    <P>
                        We note that Health IT Modules certified to § 170.315(b)(11) must support the technical capability for 
                        <E T="03">other party</E>
                         source attribute information to be entered into the Health IT Module's source attribute fields, per requirements elaborated below for final § 170.315(b)(11)(v)(B). We note that if a developer of certified health IT would like to include a capability for 
                        <E T="03">other parties</E>
                         to record source attributes into a Health IT Module in a way that shields the developer of certified health IT from having access to the 
                        <E T="03">other party</E>
                         source attributes, they may do so. However, we reiterate that developers of certified health IT are not required to receive, acquire, or otherwise obtain source attribute information for an 
                        <E T="03">other party's</E>
                         Predictive DSI unless such Predictive DSI is supplied by the developer of certified health IT as part of its Health IT Module.
                    </P>
                    <P>
                        Finally, and in consideration of comments received and the scope reductions we have made to this final certification criterion, we determined that a supportive Maintenance of Certification requirement as part of the Assurances Condition of Certification in 45 CFR 170.402(b) was necessary to fully implement our policy objectives and proposals. We have included in this final rule an Assurances Maintenance of Certification requirement that reinforces a certified health IT developer's ongoing responsibility in § 170.315(b)(11)(v)(A)(
                        <E T="03">1</E>
                        ) to enable user access to updated descriptions of source attribute information at § 170.315(b)(11)(iv)(A) and (B), to review and update as necessary IRM practices that must be applied for each Predictive DSI the health IT developer supplies as part of its Health IT Module in § 170.315(b)(11)(vi), and to ensure the ongoing public accessibility of updated summary IRM practice information as submitted to their ONC-ACB via hyperlink in § 170.523(f)(1)(xxi).
                    </P>
                    <P>
                        This Maintenance of Certification requirement is a § 170.315(b)(11)-specific instantiation of general Program requirements described in § 170.402(a) as well as an adaptation of what we proposed at § 170.315(b)(11)(vii)(D), which proposed to establish an “annual 
                        <PRTPAGE P="1254"/>
                        and, as necessary, update” requirement for developers with Health IT Modules certified to § 170.315(b)(11) (88 FR 23805). In consideration of comments received on § 170.315(b)(11) as a whole and the corresponding changes we made to the final certification criterion to focus on Health IT Module capabilities, it became clear that the ongoing transparency of source attribute and IRM practices associated with § 170.315(b)(11) would best fit under the Program as a developer-level responsibility compared to a product-level responsibility. As such, it made the most sense to shift the nature of these proposals from the more technical certification criterion to the Assurances Condition. Accordingly, we have finalized at § 170.402(b)(4) that starting January 1, 2025, and on an ongoing basis, developers of Health IT Modules certified to § 170.315(b)(11) must review and update, as necessary, source attribute information in § 170.315(b)(11)(iv)(A) and (B), risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi).
                    </P>
                    <P>First, we have finalized this Maintenance of Certification requirement to serve as a discrete connection for developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) to have complete and up-to-date descriptions of source attribute information (in § 170.315(b)(11)(iv)(A) and (B)) at the time of certification and on an ongoing basis while their Health IT Module is certified to § 170.315(b)(11). This Maintenance of Certification requirement builds on three existing Assurances Condition of Certification requirements at § 170.402(a)(1), (2) and (3), respectively, stating that a health IT developer must provide assurances to the Secretary that it “. . . will not take . . . any other action that may inhibit the appropriate exchange, access, and use of electronic health information,” “must ensure that its health IT certified under the ONC Health IT Certification Program conforms to the full scope of the certification criteria,” and “must not take any action that could interfere with a user's ability to access or use certified capabilities for any purpose within the full scope of the technology's certification.” While we believe these existing requirements within the Assurance Condition pertain to both evidence-based and Predictive DSIs, as well as IRM practices, we believe this specific additional Maintenance of Certification requirement is necessary because of the unique, evolving, and dynamic nature of DSIs. Moreover, it is important for users of health IT certified to § 170.315(b)(11) as well as the Secretary to have as an explicit assurance that developers of certified health IT are keeping source attribute information up-to-date and, as applicable, that such developers are committed to IRM practices.</P>
                    <P>
                        For example, both evidence-based and Predictive DSIs use EHI as key input data in underlying rules and models. Supplying DSIs without accompanying accurate and up-to-date documentation could inhibit the appropriate use of EHI in two ways. First, it could lead the health IT developer's customers to fail to use the DSI in appropriate ways, most obviously by omission of an updated statement of the DSI's intended use as required at § 170.315(b)(11)(iv)(B)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ). Similarly, supplying DSIs without accompanying documentation could lead to the use of a DSI on unintended populations, on individuals from groups for which the DSI does not perform adequately, or by leading to the use of a DSI for which associated risks have not been appropriately identified and mitigated. Further, supplying a DSI without accompanying documentation could inhibit the selection and use of a DSI that would make appropriate use of EHI. Without information on the DSI supplied by the developer of certified health IT, users will not be able to adequately determine whether the developer of certified health IT's supplied DSI is fit for their purpose, or whether they should select a more effective DSI.
                    </P>
                    <P>While we believe that, under our proposal, developers of certified health IT would have taken actions to continually maintain information associated with DSIs and IRM practices, in accordance with Assurances requirements in § 170.402(a)(1), (2), and (3), this Maintenance of Certification requirement adds necessary specificity to the overall Assurances Condition of Certification and ensures that developers of certified health IT are firmly aware of their ongoing obligations associated with the certification criterion at § 170.315(b)(11). Moreover, this Maintenance of Certification requirement ensures that actions taken by the developer of certified health IT enable a user to access § 170.315(b)(11)-related documentation on an ongoing basis will not inhibit the appropriate use of EHI. In establishing this Maintenance of Certification requirement, we address acute transparency concerns from public comments regarding the accuracy, relevance, and timeliness of the source attribute information provided by the developers of certified health IT. As reflected in several source attributes seeking information on the ongoing maintenance of intervention implementation and use, and in particular the validity and fairness of predictions in local data, models and data used to drive Predictive DSIs will change over time (88 FR 23792); if developers of certified health IT do not continue to keep associated attribute information up to date, their failure to do so could have adverse impacts on user trust, accuracy, usage, and safety.</P>
                    <P>Second, we have finalized in this Maintenance of Certification requirement that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) review and update as necessary risk management practices described in § 170.315(b)(11)(vi). This is substantially similar to what we proposed at § 170.315(b)(11)(vii)(D), which was to review annually and, as necessary, update IRM practice documentation. We discuss comments received to proposed § 170.315(b)(11)(vii)(D) further in this final rule preamble.</P>
                    <P>Last, we have finalized in this Maintenance of Certification requirement that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) review and update as necessary summary information provided to the developer's ONC-ACB, consistent with what we proposed at § 170.315(b)(11)(vii)(C), which required that summary information be submitted to the health IT developer's ONC-ACB via publicly accessible hyperlink, as well as what we proposed at § 170.523(f)(xxi), which required ONC-ACBs to ensure that all of the information required to be submitted by the health IT developer to meet IRM requirements in § 170.315(b)(11)(vii)(C) were available via public hyperlink. We discuss comments received to proposed § 170.315(b)(11)(vii)(C) and § 170.523(f)(xxi) further in this final rule preamble.</P>
                    <P>
                        <E T="03">Comments.</E>
                         While some commenters agreed with and were supportive of the proposed definition and our explanation of the differences between “Enables” and “Interfaces with,” several commenters expressed concern that the proposed phrase “enables or interfaces with” was overly broad when applied to the proposed definition for Predictive DSI and requested that we further define and narrow the scope of these terms. These commenters stated that ONC should clearly define the scope of activities or technologies that “enable or 
                        <PRTPAGE P="1255"/>
                        interface with” Predictive DSIs to narrow the scope of this requirement to make it clear that the HTI-1 Proposed Rule applies in situations such as, for example, when entities have contracts specifically covering the enablement and use of such technologies. Commenters also expressed concern that the phrase “enables or interfaces with” would require health IT developers to meet the transparency requirements for all third-party apps that customers utilize via § 170.315(g)(10) technology, and that it would be difficult for developers to require third parties to provide source attributes information, particularly when there is no contractual relationship between the health IT developer and 
                        <E T="03">other party</E>
                         developers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments and have modified our final scope for Health IT Modules that must provide source attribute information and our scope for which Predictive DSIs must be subject to IRM practices in response to public comment. We understand through public comments that interested parties viewed the scope contingent on “enables or interfaces with” as too broad and ambiguous, especially given that the scope of these terms would impact conditional requirements related to source attributes and risk management by way of the proposed attestation in § 170.315(b)(11)(v). In considering alternative constructions that would clarify our intent and in consideration of commenters' concerns, we have finalized a construction that narrows and replaces the two concepts of “enables,” and “interfaces with,” with “supplied by.” This modification is reflected in the finalized text of § 170.315(b)(11)(v) and regulatory text in § 170.315(b)(11)(vi) to establish conditional requirements for Health IT Modules that include an 
                        <E T="03">other party's</E>
                         Predictive DSI that is supplied by the health IT developer.
                    </P>
                    <P>
                        For example, if a user ordered a lab test using the existing certification criterion capability for computerized provider order entry-laboratory (§ 170.315(a)(3)) and the lab test result was derived from a Predictive DSI used by the laboratory, such a configuration would be out of scope and the Health IT Module would not subject to the requirements in § 170.315(b)(11)(v), because the Predictive DSI that rendered the lab test result was not supplied by (
                        <E T="03">i.e.,</E>
                         included as part of the Health IT Module) the developer of the certified health IT.
                    </P>
                    <P>
                        We believe that these modifications significantly narrow the scope of our proposal and clarify which 
                        <E T="03">other party</E>
                         Predictive DSI configurations are subject to requirements in § 170.315(b)(11) for source attributes. We also note that the phrase “supplied by” is also included in the text of § 170.315(b)(11)(vi) to establish a conditional requirement that for each Predictive DSI supplied by the health IT developer as part of its Health IT Module, is subject to risk analysis, risk mitigation, and governance, which we discuss more in section “xi. Intervention Risk Management (IRM)” later in this final rule. We believe that developers of certified health IT with Health IT Modules that supply an 
                        <E T="03">other party's</E>
                         Predictive DSI as part of their Health IT Module would be generally aware of and be well positioned to make source attribute information available for user review as well as apply IRM practices given the likelihood of a high degree of technical coordination and formalized business relationship between a developer of certified health IT and an 
                        <E T="03">other party</E>
                         in such scenarios.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern that the definition of Predictive DSI included the terms “interfaces with,” and “enabled by” could potentially incorporate test results generated using laboratory processes that contain algorithmic components, if the outputs of those tests are transmitted to an EHR, and requested that the definition exclude laboratory results because labs are already subject to other federal requirements and should not be subject to additional requirements due to their results being made available through an EHR.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for their input. However, we clarify that neither our proposed nor final definition in § 170.102 included the terms “interfaces with,” or “enabled by.” These terms of art were used in the HTI-1 Proposed Rule to establish a configuration nexus that would subject Health IT Modules to additional requirements if such Health IT Modules enabled or interfaced with a Predictive DSI. As noted above, and given that our final policy nexus is dependent on “supplied by the health IT developer as part of its Health IT Module,” we note that if the test result is generated by a Predictive DSI used by the lab itself for the generation of results but the Predictive DSI is not supplied by the developer of the certified Health IT Module, it would be out of scope of the requirements established by the final policy. As another example, if a user ordered a lab test using the existing certification criterion capability for Computerized provider order entry-laboratory (§ 170.315(a)(3)) and the lab test result was derived from a Predictive DSI used by the laboratory, such a configuration would be out of scope and the Health IT Module would not subject to the requirements in § 170.315(b)(11), because the Predictive DSI that rendered the lab test result was not supplied by the health IT developer as part of its Health IT Module.
                    </P>
                    <HD SOURCE="HD3">vi. Source Attributes</HD>
                    <P>At 88 FR 23787, we proposed in § 170.315(b)(11)(vi) that Health IT Modules certified to § 170.315(b)(11) enable a user to review a plain language description of source attribute information as indicated at a minimum via direct display, drill down, or link out from a Health IT Module. We noted that § 170.315(g)(3) “safety-enhanced design,” applies to the existing § 170.315(a)(9) criterion and in keeping with that applicability, we proposed that safety-enhanced and user-centered design processes described in § 170.315(g)(3) would apply to the new certification criterion proposed in § 170.315(b)(11) as well. We proposed to update § 170.315(g)(3) accordingly to reference the proposed § 170.315(b)(11).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters were generally split on supporting or not supporting the proposal in § 170.315(b)(11)(vi) that Health IT Modules certified to § 170.315(b)(11) enable a user to review a plain language description of source attribute information as indicated at a minimum via direct display, drill down, or link out from a Health IT Module. Those in support noted that it would have the benefit of allowing users to assess the DSI's quality and thereby enhancing trustworthiness; enable those with sufficient knowledge to understand the data to make informed purchasing decisions; and give flexibility that ensures that the recommendations and guidance provided by these systems align with the organization's unique workflows and patient populations, facilitating seamless integration into clinical practice. Several commenters agreed that user feedback can be a useful tool to support quality improvement within health IT and emphasizing transparency and customization allows healthcare organizations to tailor decision support systems to their specific needs. Other commenters urged ONC not to adopt the direct display, drill down, or link requirement observing that including too much information in the direct display can negatively impact usability and user adoption in comparison to providing rational and accessible paths to deeper information via click-paths that are based on user-centered design principles. These commenters worried that requiring “at a minimum direct 
                        <PRTPAGE P="1256"/>
                        display, drill down, or link out,” could unintentionally inhibit innovative user interfaces and user designs to enable user access to source attributes.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support, and we note that requirements originally proposed in § 170.315(b)(11)(vi) for source attributes built off more than a decade of existing expectations for source attributes in the current CDS criterion at § 170.315(a)(9)(v) where the expectation for direct display, drill down, or link out had been described at 77 FR 54215. However, in consideration of comments, we have not finalized the requirements for source attribute information to be available via direct display, drill down, or link out from a Health IT Module. Rather we have finalized a source attributes requirement in § 170.315(b)(11)(iv) without the text “at a minimum via direct display, drill down, or link out from a Health IT Module.” While we have not finalized a requirement for presenting source attribute information to users in the regulation text at § 170.315(b)(11)(iv), we reiterate the requirement in § 170.315(b)(11)(v)(A)(
                        <E T="03">1</E>
                        ) that Health IT Modules enable a limited set of identified users to access complete and up-to-date plain language descriptions of source attribute information in paragraphs § 170.315(b)(11)(iv)(A) and § 170.315(b)(11)(iv)(B). And we have also included a requirement in § 170.315(b)(11)(v)(B)(
                        <E T="03">1</E>
                        ) to enable a limited set of identified users to record, change and access the same source attribute information. The phrase “limited set of identified users” conveys that the capability is not required for all users of the Health IT Module. Rather, that the capability can be constrained to a smaller userbase that are identified to have the privileges necessary to use the capabilities in § 170.315(b)(11), including the capability to record, change, and access source attributes and source attribute information. We have provided this flexibility so that any number and configuration of users may record, change, and access source attribute information according to organizational needs. For example, if a client of a developer of certified health IT hosts source attributes for each deployed evidence-based or Predictive DSI centrally, a Health IT Module could include a hyperlink from a dashboard or other user interface to a user at the point-of-care. Additionally, this flexibility could limit record, change, and access privileges to a user who has responsibilities for an organization's procurement and implementation decisions.
                    </P>
                    <P>Finally, we did not receive any substantive or direct feedback regarding our proposal to update “safety-enhanced design,” to reference the certification criterion finalized in § 170.315(b)(11). We continue to believe that just as the CDS criterion in § 170.315(a)(9) was subject to safety-enhanced design requirements, so too should the revised criterion in § 170.315(b)(11). Thus, we have finalized our proposed modification to § 170.315(g)(3) “safety-enhanced design,” to reference the certification criterion finalized in § 170.315(b)(11).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested clarity on the proposal for source attributes noting that the proposal was ambiguous as to what source attributes would need to be implemented and requested that ONC provide more clarity on the expectation of how source attributes must be implemented in a Health IT Module. Specifically, one commenter requested clarification on whether software should support source attribution when clinically appropriate, noting that many health care providers and health systems have structures in place to track appropriate source attributes. One commenter requested additional clarity on how the information being available at the point of care should be used in real time stating that most of the source attribute information will be relevant to the organization while it makes procurement and implementation decisions versus during care delivery.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the commenters' suggestions and have finalized our proposal with modifications in consideration of these and related comments. We have made several modifications to reduce the ambiguity cited by commenters related to the source attributes proposals. We have separately identified requirements related to accessing up-to-date and complete information for DSI supplied in the Health IT Module at § 170.315(b)(11)(v)(A) and requirements related to enabling customers to modify source attributes and source attribute information for DSI at § 170.315(b)(11)(v)(B). We also separately list source attribute categories for evidence-based and Predictive DSI at § 170.315(b)(11)(iv)(A) and (B), respectively. We believe that information available as source attributes will have value both as reference information to individual users evaluating the use of a DSI on an individual patient—for instance, by assessing whether it has been recently evaluated at their health system and whether it has been shown to perform well for a patient like theirs—and for the organization during procurement, implementation, and analysis.
                    </P>
                    <P>To further address potential ambiguity about how source attributes must be implemented in Health IT Modules certified to § 170.315(b)(11), we have finalized uniform requirements in § 170.315(b)(11)(iv) for Health IT Modules to support source attributes listed at § 170.315(b)(11)(iv)(A) and (B). This means that all Health IT Modules certified to § 170.315(b)(11) must support the categories, but not necessarily the content, for each source attribute listed at § 170.315(b)(11)(iv)(A) and (B). For example, Health IT Modules must support user access to complete and up-to-date source attribute information in § 170.315(b)(11)(iv)(B) only if the Predictive DSI is supplied by the health IT developer as part of its Health IT Module. </P>
                    <P>We have provided additional specificity about the technical capabilities required to support source attributes at § 170.315(b)(11)(v). As described above, we have not finalized our proposal for an attestation statement. Rather, we have finalized in § 170.315(b)(11)(v) a set of four capabilities that Health IT Modules must support related to source attributes. Each of these capabilities was proposed in different parts of § 170.315(b)(11) in the HTI-1 Proposed Rule.</P>
                    <P>
                        First, we have finalized requirements for “Source attribute access and modification” in § 170.315(b)(11)(v). Specifically, we finalized a requirement in § 170.315(b)(11)(v)(A)(
                        <E T="03">1</E>
                        ) that is substantially similar to what we proposed in § 170.315(b)(11)(vi) to “Enable a user to review a plain language description of source attribute information as indicated and at a minimum via direct display, drill down, or link out from a Health IT Module . . . .” The finalized “access” requirement states in § 170.315(b)(11)(v)(A)(
                        <E T="03">1</E>
                        ) that for evidence-based and Predictive DSIs supplied by the health IT developer, the Health IT Module must enable a limited set of identified users to access complete and up-to-date plain language descriptions of source attribute information specified in § 170.315(b)(11)(iv)(A) and (B) as finalized. As discussed earlier, we have not finalized proposed requirements for Health IT Modules to make source attribute information available via direct display, drill down, or link out.
                    </P>
                    <P>
                        Second, we have finalized at § 170.315(b)(11)(v)(A)(
                        <E T="03">2</E>
                        ) that for Predictive DSIs supplied by the health IT developer as part of its Health IT Module, the Health IT Module must 
                        <PRTPAGE P="1257"/>
                        indicate when information is not available for review for source attributes in paragraphs (b)(11)(iv)(B)(
                        <E T="03">6</E>
                        ); (b)(11)(iv)(B)(
                        <E T="03">7</E>
                        )(
                        <E T="03">iii</E>
                        ), (
                        <E T="03">iv</E>
                        ), and (
                        <E T="03">v</E>
                        ); (b)(11)(iv)(B)(
                        <E T="03">8</E>
                        )(
                        <E T="03">ii</E>
                        ) and (
                        <E T="03">iv</E>
                        ); and (b)(11)(iv)(B)(
                        <E T="03">9</E>
                        ). This requirement is finalized as a modified version of what was proposed at § 170.315(b)(11)(vi)(D)(
                        <E T="03">1</E>
                        ) and § 170.315(b)(11)(vi)(D)(
                        <E T="03">2</E>
                        ), which required Health IT Modules to indicate a source attribute is missing if the source attribute included the “if available” phrase. We clarify that per conformance with this certification criterion and its associated maintenance of certification requirement adopted as part of § 170.402(b)(4), if and when information related to these source attributes are generated, the developer of certified health IT must make this information available to users. For example, if the developer of certified health IT gets newly available information on the validity of the intervention in local data (§ 170.315(b)(11)(iv)(B)(
                        <E T="03">8</E>
                        )(
                        <E T="03">ii</E>
                        )) following the deployment of a Predictive DSI, that information must be made available as source attributes information to reflect up-to-date descriptions of source attributes.
                    </P>
                    <P>
                        Third and fourth, we have finalized two requirements related to the ability to “modify” source attributes and source attribute information at § 170.315(b)(11)(v)(B). At § 170.315(b)(11)(v)(B)(
                        <E T="03">1</E>
                        ), we have finalized a requirement that for evidence-based DSIs and Predictive DSIs, the Health IT Module must enable a limited set of identified users to record, change, and access source attributes in paragraphs (b)(11)(iv)(A) and (B) of this section. At § 170.315(b)(11)(v)(B)(
                        <E T="03">2</E>
                        ) we have finalized that, for Predictive DSIs, a Health IT Module must enable a limited set of identified users to record, change, and access additional source attributes not specified in § 170.315(b)(11)(iv)(B). These requirements are substantially similar to what we proposed in § 170.315(b)(11)(vi)(E) while retaining the ability to access or review this information as would have been required in proposed § 170.315(b)(11)(v). In proposed § 170.315(b)(11)(vi)(E) we proposed that a Health IT Module must enable a limited set of identified users to “author and revise,” source attribute information beyond source attributes listed. We note that the capability to record and change replaces the proposed capability to author and revise.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested guidance on the level of detail required in these descriptions and specification of “plain language descriptions” for which audience (
                        <E T="03">e.g.,</E>
                         developers, clinicians, and other end-users) and guidelines on how to present this information, noting the concern that a user may have difficulty finding the required documentation depending on how the interface is designed. Commenters expressed concern that the proposal to enable a user to review a plain language description of source attribute information could result in legal liability and vulnerability for clinicians and health care providers, underscoring the need that the information provided in the new source attributes for Predictive DSI are useful and understandable.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their concerns. We note that requirements related to a plain language description are now included at § 170.315(b)(11)(v)(A)(
                        <E T="03">1</E>
                        ). When we indicate “plain language description,” we mean language that the intended audience can readily understand and use because that language is clear, concise, well-organized, accurately describes the information, and follows other best practices of plain language writing. We encourage model developers to consider what information would be useful for users to determine if a Predictive DSI is FAVES without providing difficult to understand technical details. We agree that providing this information in a useful form will be essential. Comments regarding legal liability are outside the scope of this rulemaking. Therefore, we decline to finalize any such change.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested clarity regarding cases where third-party IT that is enabled or interfaced with certified health IT but is modified by users or a different third-party developer such that the added functionality results in the generation of a Predictive DSI, and whether such cases would be subject to conditional requirements for source attributes listed in § 170.315(b)(11)(vi)(A) and deployment of or engagement in intervention risk management practices discussed in § 170.315(b)(11)(vii).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In a scenario where an 
                        <E T="03">other party</E>
                         technology is modified by a different 
                        <E T="03">other party (e.g.,</E>
                         users or a different third-party developer) such that the initial technology meets the definition of a Predictive DSI, we would categorize the modified technology as a Predictive DSI developed by an 
                        <E T="03">other party.</E>
                         A Health IT Module may be expected to have the technical capability for users to record, change and access source attributes of this modified technology, and may be expected to provide up-to-date source attribute information if the Predictive DSI is supplied by the developer of certified health IT as part of the Health IT Module.
                    </P>
                    <HD SOURCE="HD3">vii. Source Attributes—Demographic, SDOH, and Health Status Assessment Data Use</HD>
                    <P>
                        We proposed at 88 FR 23787 to include as source attributes in § 170.315(b)(11)(vi)(A)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">4</E>
                        ) the source attributes currently found in § 170.315(a)(9)(v)(A)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">4</E>
                        ). Additionally, we proposed that the use of three additional specific types of data in a DSI be included as source attributes in § 170.315(b)(11)(vi)(A)—Demographic data elements in § 170.315(b)(11)(vi)(A)(
                        <E T="03">5</E>
                        ), SDOH data elements in § 170.315(b)(11)(vi)(A)(
                        <E T="03">6</E>
                        ), and Health Status Assessment data elements in § 170.315(b)(11)(vi)(A)(
                        <E T="03">7</E>
                        ). We noted at 88 FR 23787 that “types of data in a DSI” means that the DSI includes any of these data as inputs or otherwise expressly rely on any of these data in generating an output or outputs. We explained that by proposing to modify the source attributes as part of proposed § 170.315(b)(11)(vi)(A) relative to the existing attributes in § 170.315(a)(9)(v)(A), we expected that information would be made available to users if the specific data elements within these three data categories were used in the DSI.
                    </P>
                    <P>
                        <E T="03">Context note.</E>
                         We note for readers that while all of the proposals just summarized were part of proposed § 170.315(b)(11)(vi), we have finalized modified versions of these requirements as part of § 170.315(b)(11)(iv)(A). As a result, we discuss the finalized requirements with that context in mind.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters supported the proposal to include the requirement that certified Health IT Modules should provide users with source attributes for DSI, including the three additional specific types of data of demographic, SDOH, and health status assessment data elements. These commenters stated that it would have the benefit of enabling individuals and organizations to understand the nature of certified health IT, whether there are inherent biases, and how best to use the technology for a specific patient population. Commenters also stated that requiring developers of certified health IT to report on these data elements' inclusion will assist providers in both ensuring the whole patient is cared for and that there is transparency as part of that whole-person care. Commenters noted that the proposed requirements would address pressing concerns that AI algorithms can reinforce biases related 
                        <PRTPAGE P="1258"/>
                        to socioeconomic status, race, ethnicity, sexual orientation, gender identity, sex, and other identities and conditions, observing that recent advances in AI stand to potentially harm patients by reinforcing implicit and explicit biases that do not reflect the diverse population of America and that may only increase health inequities. Commenters supported the public transparency requirements for source attribute information as an important measure to avoid exacerbating these inequities.
                    </P>
                    <P>A minority of commenters did not support the proposal stating that the HTI-1 Proposed Rule would create significant implementation burden with unclear benefits. One commenter suggested that the HTI-1 Proposed Rule may also paradoxically increase disparities by reducing innovation and the implementation of DSIs due to increased regulatory burden. One commenter expressed concern that the preamble was unclear on what it meant for an evidence-based decision support intervention to “use” or “include” patient demographics and observations, SDOH, or health status assessments.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support and agree that by highlighting when an evidence-based DSI uses patient demographics, SDOH, or health status assessments data elements,
                        <SU>115</SU>
                        <FTREF/>
                         users are empowered to interrogate and ensure that the DSI is appropriate. We believe that identification of race, ethnicity, language, age (date of birth), sexual orientation, gender information, SDOH, and health status assessments, such as disability, data elements, if included as part of an evidence-based DSI, would greatly improve the possibility of identifying and mitigating the risks of employing evidence-based DSIs for patient care, including those related to exacerbating racial disparities and promoting bias. We believe that this requirement represents a low burden that is unlikely to reduce innovation and implementation of DSIs. We also thank commenters for identifying ambiguities in what it means for an evidence-based decision support intervention to “use” or “include” these data elements. We clarify that our intention is to enable a user to understand if one or more of these data elements are included as inputs or otherwise expressly relied upon to generate an output in an evidence-based DSI. We also intend that, if the data elements are included, the user is informed which one(s) are used in the evidence-based DSI. This means that a user must be able to review whether a data element relevant to those categories in § 170.315(b)(11)(iv)(A)(
                        <E T="03">5</E>
                        )-(
                        <E T="03">13</E>
                        ) (as expressed by the standards in § 170.213) is used in the evidence-based DSI, and if so, which specific data element or elements are used in the evidence-based DSI.
                    </P>
                    <FTNT>
                        <P>
                            <SU>115</SU>
                             For purposes of this final rule, health status assessments are assessments of a health-related matter of interest, importance, or worry to a patient, patient's family, or patient's health care provider that could identify a need, problem, or condition. See ONC's Interoperability Standards Advisory (ISA) at 
                            <E T="03">https://www.healthit.gov/isa/uscdi-data-class/health-status-assessments#uscdi-v3.</E>
                        </P>
                    </FTNT>
                    <P>
                        We do not prescribe how this information is communicated to a user, nor do we prescribe a minimum level of context at this time. For example, we do not require that a source attribute indicating the use of an SDOH data element in § 170.315(b)(11)(iv)(A)(
                        <E T="03">6</E>
                        ) must describe 
                        <E T="03">how</E>
                         the data element is used as part of the evidence-based DSI. Instead, we require a Health IT Module to enable a user to review whether an SDOH data element is used as part of the evidence-based DSI and which SDOH data element (as expressed by the standards in § 170.213) is used as part of the evidence-based DSI.
                    </P>
                    <P>
                        After consideration of comments, we have finalized as part of § 170.315(b)(11)(iv)(A) patient demographic, SDOH, and health status assessment data elements in § 170.315(b)(11)(iv)(A)(
                        <E T="03">5</E>
                        ) through (
                        <E T="03">13</E>
                        ) as expressed in the standards in § 170.213. We note that, consistent with the dates established in § 170.213, compliance with USCDI v1 will be required to initially meet this certification criterion until compliance with USCDI v3 becomes required as part of this certification criterion (
                        <E T="03">i.e.,</E>
                         January 1, 2026). As a result, for the first compliance date associated with § 170.315(b)(11) a Health IT Module may include, but is not required to include, identification of the use of patient demographic data elements that are only found in USCDI v3 as part of evidence-based DSIs in § 170.315(b)(11)(iv)(A)(
                        <E T="03">5</E>
                        )-(
                        <E T="03">13</E>
                        ).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters responded to our solicitation for comment on whether we should require a certain format or order in which these source attributes must appear to users. Commenters noted that the proposed source attribute requirements would require each organization to craft their own documentation process and suggested that ONC collaborate with interested parties to implement and refine a standards-based approach for capturing and sharing source attributes, including sharing both machine-readable and human-readable tables/lists of DSI source attribute information. Commenters also observed that requiring information about DSIs to be submitted in a standard format will focus the scope of the information disclosed, create consistency in the kind of information shared about these AI tools, and contribute to a presentation of this information for end users that is repeatable and digestible. Commenters noted that without a standardization and strategic placement, providers moving across organizations will experience the added stress of learning each organization's method of addressing DSI, compounding burden. One commenter supported including HL7 consensus-based implementation guides for AI information, and another commenter recommended that ONC should produce a document format for DSI developers to use in conveying information to EHR developers and interface specialists. One commenter suggested that there are two common ways to present this type of long list of data: alphabetically or by type (often organized alphabetically underneath each category) and recommended categorizing by type of data then presenting each list therein alphabetically. For example: Demographic Data: date of birth, race, sex Health Status: disability status, smoking status.
                    </P>
                    <P>One commenter observed that to implement a standardized format may be burdensome for health IT developers but also will be beneficial to reduce bias in decision making and will encourage smaller, third-party applications to be more transparent and responsible in their development, stating that there are potential benefits to requiring documentation of what a clinical decision support algorithm does, and provides certainty that a level of testing and trials has been done to ensure the relevance and accuracy of the model.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments received regarding a standardized format for source attribute information. We noted in the HTI-1 Proposed Rule that we were not aware of widely agreed upon best practices for the format in which these elements or source attributes information should be displayed. We are also not aware of a consensus-based standardized format that might best meet the objective described by the commenter to reduce bias in decisions making. However, we are aware of industry efforts to standardize a format to display information about technology in the form of a “model card” or “nutritional label” for healthcare (88 FR 23794). We did not propose a specific format for source attributes, and we decline to finalize any specific formats. We believe 
                        <PRTPAGE P="1259"/>
                        this represents an ideal space for interested parties across industry, academia, government, and the non-profit sector (such as SDOs and patient advocacy organizations) to collaborate. We note that part of our rationale for being flexible in the use of standardized formats and placement of source attributes within users' workflows is precisely because there is a lack of consensus. We look forward to working with interested parties to develop consensus-based standards across numerous and far-reaching types of use cases.
                    </P>
                    <HD SOURCE="HD3">viii. Source Attributes for Predictive Decision Support Interventions</HD>
                    <P>
                        At 88 FR 23788-23795, we proposed source attributes applicable for all Predictive DSIs that are enabled by or interface with certified Health IT Modules certified to § 170.315(b)(11). These source attributes were intended to provide users with greater insight into the model incorporated into a particular Predictive DSI and intended to provide information for an array of uses, including in support of so-called “model cards” or algorithm “nutrition labels” that have been described by others.
                        <SU>116</SU>
                        <FTREF/>
                         This proposed requirement applied to developers of certified health IT that attest “yes” in § 170.315(b)(11)(v)(A).
                    </P>
                    <FTNT>
                        <P>
                            <SU>116</SU>
                             Mitchell, Margaret, et al. “Model cards for model reporting.” Proceedings of the conference on fairness, accountability, and transparency. 2019.
                        </P>
                    </FTNT>
                    <P>
                        We noted that the proposals for source attributes would not require disclosing or sharing intellectual property (IP) existing in the developer's health IT, including 
                        <E T="03">other parties'</E>
                         IP. We reiterated that source attributes in § 170.315(b)(11)(vi) would not require disclosure of proprietary information or IP (88 FR 23788). We also noted that if developers of certified health IT would like to include a capability for 
                        <E T="03">other parties</E>
                         to record source attributes into a Health IT Module in a way that shields the developer of certified health IT from having access to the 
                        <E T="03">other party</E>
                         source attributes, they could do so, but that this was not proposed as a required technical capability within the proposed criterion.
                    </P>
                    <HD SOURCE="HD3">New Source Attributes for Predictive DSI</HD>
                    <P>At 88 FR 23789, we proposed to add fourteen new source attributes for Predictive DSIs that enable or interface with Health IT Modules. Consistent with our proposals in § 170.315(b)(11)(vi), we proposed that these new source attributes listed in § 170.315(b)(11)(vi)(C) would be in plain language and available for user review via direct display, drill down, or link out from a Health IT Module certified to § 170.315(b)(11) and for which the developer attested “yes” in § 170.315(b)(11)(v)(A).</P>
                    <P>
                        We clarified that we proposed to require that developers must enable a user to review a plain language description of source attribute information as indicated and at a minimum via direct display, drill down, or link out from a Health IT Module and that information on these source attributes must be provided by the developer of certified health IT unless the attribute contained the phrase “if available” (discussed at 88 FR 23789) or was developed by an 
                        <E T="03">other party,</E>
                         as proposed at § 170.315(b)(11)(vi)(D) discussed at 88 FR 23795-23796.
                    </P>
                    <P>
                        <E T="03">Context note.</E>
                         We note for readers that while all of the proposals just summarized were part of proposed § 170.315(b)(11)(vi)(C), we have finalized modified versions of these requirements as part of § 170.315(b)(11)(iv)(B). As a result, we discuss the finalized requirements with that context in mind.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters were mixed in their support or opposition to requirements for source attributes for Predictive DSI, with those in support noting that it would create greater transparency for patients and providers that is key to building trust in AI. Commenters who were supportive noted that it would be critical for the end user to understand how a Predictive DSI is developed, evaluated, and how it should be used appropriately. Commenters also noted that health care providers would benefit because transparency promotes the exercise of a provider's judgment at the point of care, which can help avoid errors and mitigate algorithmic biases, and that source attributes will help organizations make informed decisions around potential implementation. One commenter noted that complex predictive models that incorporate difficult-to-observe validity or fairness issues may lead to harm if left unchecked, resulting in bias that can lead to decisions that can have a collective, disparate impact on certain groups of people even without the programmer's intention to discriminate.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback and their support. As expressed in our proposals for § 170.315(b)(11), we believe that transparency is a prerequisite for high-quality Predictive DSIs to be trusted by clinicians, patients, health systems, software developers, and other interested parties. We believe that transparency can help to reduce the harm of complex predictive models by informing the use, disuse, updating or decommissioning of such models. As described in more detail below, we have finalized in § 170.315(b)(11)(iv)(B) modified versions of our proposals for Predictive DSI-specific source attributes.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters did not support our proposal, with many expressing concerns that our proposal is too prescriptive and limiting to industry innovation, the source attribute categories and disclosure requirements create unnecessary burden on health IT developers and providers, and stifle competition. Several commenters were concerned that the proposed source attribute disclosure requirements could compromise patient privacy and requested clarification on the granularity of data elements that developers must disclose. Commenters recommended ONC limit the type of data that is made publicly available from high-impact DSIs to protect patient information privacy and security and safeguard protected health information (“PHI”) or sensitive data.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We respectfully disagree with these commenters. In developing proposed source attributes for Predictive DSIs, we sought a balance between limited prescriptiveness and sufficient detail to enable thorough transparency of source attribute information to users. Our selection of the proposed attributes was guided by reviews of existing model reporting guidelines, including seventeen different sets of industry- and academia-developed recommendations for information to be reported on models and related standards.
                        <FTREF/>
                        <SU>117</SU>
                          
                        <PRTPAGE P="1260"/>
                        Because these guidelines are designed to support innovation and competition in the development and validation of predictive models in the academic literature, we believe that their use will similarly leave sufficient space for innovation by a variety of entities. In our review, we emphasized attributes that: (1) were most commonly included in the reviewed reporting guidelines; (2) we believed would be most interpretable by both health IT professionals and users; (3) were focused on identifying issues of bias; and (4) were intended to show that the model would perform effectively outside of the specific context in which it was developed. In finalizing Predictive DSI source attributes in § 170.315(b)(11)(iv)(B), we have provided information on what we believe should be included in each attribute based on our understanding of the current best practices in this area. However, given the varied technologies, applications, and contexts in which Predictive DSIs may be used, we have sought to keep requirements sufficiently flexible to meet varied use cases. We note that under that this policy establishes different requirements for developers of certified health IT that supply Predictive DSIs versus those certified health IT developers that do not supply Predictive DSIs. Many developers of certified health IT that do not supply a Predictive DSI as part of their Health IT Module are among those developers with smaller revenues and fewer clients. These developers will be able to certify to the criterion at § 170.315(b)(11) while expending limited additional development resources on products they have certified currently. Specifically, these developers will likely have no costs related to providing complete and up-to-date source attribute information for Predictive DSI supplied by the developer or engaging in risk management and annually update risk management information.
                    </P>
                    <FTNT>
                        <P>
                            <SU>117</SU>
                             Scott, Ian, Stacy Carter, and Enrico Coiera. “Clinician checklist for assessing suitability of machine learning applications in healthcare.” 
                            <E T="03">BMJ Health</E>
                             &amp; 
                            <E T="03">Care Informatics</E>
                             28.1 (2021).
                        </P>
                        <P>
                            Liu X, Cruz Rivera S, Moher D, Calvert MJ, Denniston AK; SPIRIT-AI and CONSORT-AI Working Group. Reporting guidelines for clinical trial reports for interventions involving artificial intelligence: the CONSORT-AI extension. 
                            <E T="03">Nat Med.</E>
                             2020;26(9):1364-1374. doi:10.1038/s41591-020-1034-x.
                        </P>
                        <P>
                            Moons KGM, Kengne AP, Woodward M, et al. Risk prediction models, I: development, internal validation, and assessing the incremental value of a new (bio)marker. 
                            <E T="03">Heart.</E>
                             2012;98(9):683-690. doi:10.1136/heartjnl-2011-301246.
                        </P>
                        <P>
                            Rivera SC, Liu X, Chan AW, Denniston AK, Calvert MJ; SPIRIT-AI and CONSORT-AI Working Group. Guidelines for clinical trial protocols for interventions involving artificial intelligence: the SPIRIT-AI Extension. 
                            <E T="03">BMJ.</E>
                             2020;370:m3210. doi:10.1136/bmj.m3210.
                        </P>
                        <P>
                            Steyerberg EW, Vergouwe Y. Towards better clinical prediction models: seven steps for development and an ABCD for validation. 
                            <E T="03">Eur Heart J.</E>
                             2014;35(29):1925-1931. doi:10.1093/eurheartj/ehu207.
                        </P>
                        <P>
                            Moons KGM, de Groot JAH, Bouwmeester W, et al. Critical appraisal and data extraction for 
                            <PRTPAGE/>
                            systematic reviews of prediction modelling studies: the CHARMS checklist. 
                            <E T="03">PLoS Med.</E>
                             2014;11(10):e1001744.
                        </P>
                        <P>
                            Collins GS, Reitsma JB, Altman DG, Moons KGM. Transparent Reporting of a Multivariable Prediction Model for Individual Prognosis or Diagnosis (TRIPOD): the TRIPOD statement. 
                            <E T="03">Br J Surg.</E>
                             2015;102(3):148-158.
                        </P>
                        <P>
                            Cohen JF, Korevaar DA, Altman DG, et al. STARD 2015 guidelines for reporting diagnostic accuracy studies: explanation and elaboration. 
                            <E T="03">BMJ Open.</E>
                             2016;6(11):e012799. doi:10.1136/bmjopen-2016-012799.
                        </P>
                        <P>
                            Luo W, Phung D, Tran T, et al. Guidelines for developing and reporting machine learning predictive models in biomedical research: a multidisciplinary view. 
                            <E T="03">J Med internet Res.</E>
                             2016;18(12):e323. doi:10.2196/jmir.5870.
                        </P>
                        <P>
                            Breck E, Cai S, Nielsen E, Salib M, Sculley D. The ML Test Score: a rubric for ML production readiness and technical debt reduction. 
                            <E T="03">Proceedings of the 2017 IEEE International Conference on Big Data.</E>
                             December 11-14, 2017:1123-1132. doi:10.1109/BigData.2017.8258038.
                        </P>
                        <P>
                            Wolff RF, Moons KGM, Riley RD, et al; PROBAST Group†. PROBAST: a tool to assess the risk of bias and applicability of prediction model studies. 
                            <E T="03">Ann Intern Med.</E>
                             2019;170(1):51-58. doi:10.7326/M18-1376.
                        </P>
                        <P>
                            Mitchell M, Wu S, Zaldivar A, et al. Model Cards for model reporting. In: 
                            <E T="03">Proceedings of the Conference on Fairness, Accountability, and Transparency.</E>
                             Association for Computing Machinery; January 29, 2019.
                        </P>
                        <P>
                            Sendak MP, Gao M, Brajer N, Balu S. Presenting machine learning model information to clinical end users with model facts labels. 
                            <E T="03">NPJ Digit Med.</E>
                             2020;3:41. doi:10.1038/s41746-020-0253-3.
                        </P>
                        <P>
                            Hernandez-Boussard T, Bozkurt S, Ioannidis JPA, Shah NH. MINIMAR (Minimum Information for Medical AI Reporting): developing reporting standards for artificial intelligence in health care. 
                            <E T="03">J Am Med Inform Assoc.</E>
                             2020;27(12):2011-2015.doi:10.1093/jamia/ocaa088.
                        </P>
                        <P>
                            Norgeot B, Quer G, Beaulieu-Jones BK, et al. Minimum Information About Clinical Artificial Intelligence Modeling: the MI-CLAIM checklist. 
                            <E T="03">Nat Med.</E>
                             2020;26(9):1320-1324. doi:10.1038/s41591-020-1041-y.
                        </P>
                        <P>
                            Silcox C, Dentzer S, Bates DW. AI-enabled clinical decision support software: a “trust and value checklist” for clinicians. 
                            <E T="03">NEJM Catalyst.</E>
                             2020;1(6). doi:10.1056/CAT.20.0212.
                        </P>
                        <P>
                            Vasey, Baptiste, et al. “Reporting guideline for the early-stage clinical evaluation of decision support systems driven by artificial intelligence: DECIDE-AI.” 
                            <E T="03">Nature medicine</E>
                             28.5 (2022): 924-933.
                        </P>
                    </FTNT>
                    <P>We believe that our finalized Predictive DSI source attributes strike a balance between prescriptiveness and flexibility that is necessary to foster a nascent information ecosystem that can help users understand whether the Predictive DSI they are using (as supplied by their health IT developer as part of its Health IT Module) is FAVES. Moreover, we believe these source attributes help establish a consistent transparency baseline, or foundation, especially given that we have not established requirements for specific measures. Rather, we encourage industry, academic, professional associations, and other interested parties to determine which information best fits each use case. We also do not believe that the information in source attributes creates a risk to patient privacy, given the level of detail at which information should be provided, as described in more detail in response to concerns related to intellectual property. We also note that we are affording flexibilities related to source attributes that are only required once information for them become available, such as source attributes related to validity and fairness of prediction in external and local data. We have finalized the categories of source attributes related to Predictive DSIs at § 170.315(b)(11)(iv)(B) with modifications and clarifications to source attribute category subparagraphs, described below in this final rule.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters, including health information technology companies, insurance companies, software developers, and professional trade associations, expressed concerns that providing users with access to information described as part of source attributes would expose proprietary information regarding the predictive algorithm or model and risk exposing intellectual property (IP) among other risks, including that disclosure of such information would stifle competition and innovation. Some commenters suggested ONC specify that the information in our proposals does not include confidential information such as IP. Some commenters were concerned that source attributes could enable reconstruction of the algorithm and that it would create a power imbalance between small and startup “
                        <E T="03">other parties”</E>
                         and large incumbent developers of certified health IT, which could either refuse to display source attributes from 
                        <E T="03">other parties</E>
                         or use information in those source attributes inappropriately. While many commenters were vague in their concerns related to revealing IP and trade secrets a small number of commenters identified the “Intervention Development” category of source attributes as problematic and another commenter noted that the output of the intervention would constitute IP. During further fact-finding, commenters mentioned specific concerns around source attribute information on how input and output variables were identified, as well as the model parameters, hyperparameters, or the results of tuning, which they described as crucial pieces of intellectual property, proprietary information, or trade secrets. Another commenter included “model type, target definition (intended use), and inputs” as information that could include IP or proprietary information.
                    </P>
                    <P>
                        Several commenters suggested ways to mitigate IP and proprietary information concerns, including listing data classes instead of data elements used in the algorithm; limiting source attribute information to summary information for high-risk use cases only; limiting source attribute requirements to algorithms developed by developers of certified health IT; requiring only links to DSIs centrally supported by a government-sponsored resource and to information maintained by the FDA if the DSI is regulated as a medical device; and giving developers the ability to exclude or redact source attribute 
                        <PRTPAGE P="1261"/>
                        information they considered proprietary.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As described in detail below, we respectfully disagree with the claims that our proposed, and now final, requirements for source attributes in § 170.315(b)(11)(iv)(B) would result in disclosures of IP, trade secrets, or proprietary information. Nor do we believe that our requirements for source attributes would stifle competition and innovation. Given the overall scope changes and numerous clarifications offered through this final rule to narrow health IT developer's scope of responsibilities (to only those Predictive DSIs that are supplied as part of its Health IT Module) we believe we have substantively address commenters' concerns regarding exposure of proprietary information to 
                        <E T="03">other parties</E>
                         as well as exposure to proprietary information originating from 
                        <E T="03">other parties.</E>
                         Additionally, we believe that the transparency needs are so acute for Predictive DSIs that the public benefit outweighs any remaining concerns. Overall, we anticipate that better information regarding Predictive DSIs will bolster the use of high-quality, fair, appropriate, valid, effective, and safe predictive algorithms across the healthcare landscape.
                    </P>
                    <P>
                        First, we do not agree that the information we require for Predictive DSI source attributes is new or novel within the healthcare context, presenting authors of Predictive DSIs with new or novel concerns related to IP or proprietary information. We note that we analyzed and drew from more than a dozen widely accepted and used reporting guidelines, used by researchers and developers to demonstrate the validity of algorithms in peer-reviewed literature.
                        <SU>118</SU>
                        <FTREF/>
                         We believe that much of the same information required for publication by the 
                        <E T="03">New England Journal of Medicine</E>
                         or the 
                        <E T="03">Journal of the American Medical Association,</E>
                         for example, ought to be routinely and consistently available for user review to improve the trustworthiness of Predictive DSIs. We note that some reporting guidelines, from which we draw our own source attributes, have more than 15,000 citations across peer-reviewed, academic literature.
                        <SU>119</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>118</SU>
                             See footnote 117.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>119</SU>
                             Table 1. Summary of 15 Model Reporting Guideline Papers. Lu JH, Callahan A, Patel BS, et al. Assessment of Adherence to Reporting Guidelines by Commonly Used Clinical Prediction Models From a Single Vendor: A Systematic Review. 
                            <E T="03">JAMA Netw Open.</E>
                             2022;5(8):e2227779. doi:10.1001/jamanetworkopen.2022.27779.
                        </P>
                    </FTNT>
                    <P>Second, we have clarified the scope of our requirements by adding detail to the information expected as part of source attributes in what is now finalized at § 170.315(b)(11)(iv)(B). We note that these explicit requirements in regulation text mirror the requirements described previously in preamble or represent a subset of requirements previously described in preamble. The information required in source attributes is not intended to include detailed information on model parameters, hyperparameters, detailed specifics around how input or output variables are defined, transformed, or otherwise operationalized. We do not believe that information at that level of detail is necessary for source attributes in § 170.315(b)(11)(iv)(B) or necessary for users of a Predictive DSI to determine whether it is fair, appropriate, valid, effective, and safe.</P>
                    <P>
                        Third, as it relates to “Intervention Development,” source attributes, which include input features, such as exclusion and inclusion criteria that influenced the data set; use of race, ethnicity, language (REL), SDOH, and health assessment variables as input features; and a description of relevance of training data to intended deployed setting, we note that these source attributes are important to give users a sense of whether they ought to use the Predictive DSI on an individual in front of them, or on individuals generally seen within the user's organization. Understanding whether specific input features, such as race, sex, or food insecurity is part of the training data set for a Predictive DSI could present a user with critical information on its relevance and validity to individual patients or patient cohorts for which the Predictive DSI is being applied. We further ask in § 170.315(b)(11)(iv)(B)(
                        <E T="03">4</E>
                        )(
                        <E T="03">iii</E>
                        ) for some sense of how representative demographic variables are within a Predictive DSI's training data set, which could be equally important if the Predictive DSI was trained on data dominated by one racial group and applied to a different group.
                    </P>
                    <P>
                        To further mitigate concerns around IP, we have limited the input features that must be included to those listed at § 170.315(b)(11)(iv)(A)(
                        <E T="03">5</E>
                        )-(
                        <E T="03">13</E>
                        ). We understand that resources are expended to identify and operationalize numerous input features to improve Predictive DSI performance. We believe this list narrows the scope of features that must be reported and addresses concerns about revealing IP underlying curation of input features more broadly. Furthermore, in developing information for source attributes, we encourage model developers to consider the level of information that would be useful for health systems and end users to best determine if a Predictive DSI is FAVES without providing difficult to understand technical details that might reveal trade secretes or proprietary information. We also reiterate that information provided should be described in plain language, as stated at § 170.315(b)(11)(v)(A)(
                        <E T="03">1</E>
                        ).
                    </P>
                    <P>We disagree with commenters concerns that identifying the output of the intervention would constitute IP. We provided an example of a prediction of the likelihood that an individual will be readmitted among individuals recently discharged (88 FR 23789). We do not believe that the description of an output, at the low level of detail provided in the example, is likely to constitute intellectual property or trade secrets. We believe that a description of the output produced by the model, along with “intended use,” is foundational to understanding how the model is meant to be deployed and used.</P>
                    <P>Fourth, we appreciate the many commenters that raised IP and proprietary information concerns while also providing ways to mitigate those concerns, primarily by limiting the number or the scope of source attributes that should be available to users. Based on the scope changes to final § 170.315(b)(11) and other clarifications issued throughout this final rule, we have not finalized additional mitigation suggestions by commenters. We believe that the clarifications provided as part of this response on the level of detail required for source attributes (as well as other corresponding responses below) will sufficiently mitigate concerns related to IP.</P>
                    <P>
                        Last, while we understand concerns raised by commenters regarding a potential to create a power imbalance between small and startup “
                        <E T="03">other parties”</E>
                         and large incumbent developers of certified health IT, which could either refuse to display source attributes from 
                        <E T="03">other parties</E>
                         or use information in those source attributes inappropriately, we believe our finalized scope for Predictive DSI source attributes addresses these concerns. Particularly, we note that these source attributes must be complete and up-to-date if they are supplied by the health IT developer as part of its Health IT Module. In this scenario, 
                        <E T="03">other party</E>
                         source attributes could be directly supplied to a developer certified health IT's customer (who will have both the ability to select this 
                        <E T="03">other party's</E>
                         Predictive DSI and have a Health IT Module support Predictive DSI source attribute categories for the 
                        <E T="03">other party's</E>
                         source attributes, even if their developer 
                        <PRTPAGE P="1262"/>
                        does not supply a Predictive DSI as part of its Health IT Module, due to requirements at § 170.315(b)(11)(iii)(B) and § 170.315(b)(11)(iv)(B)). Further, if developer of certified health IT a with Health IT Module certified to § 170.315(b)(11) would like to include a capability for 
                        <E T="03">other parties</E>
                         to record source attributes into a Health IT Module in a way that shields the developer of certified health IT from having access to the other party source attributes, the developer of certified health IT may do so.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters were concerned that our proposal requires health IT software developers to expend significant resources to gather information from numerous sources and is an unnecessary burden. Specifically, commenters noted that requiring developers of certified health IT to monitor, catalog, request information, and conduct analysis requires significant resources that will need to be redirected from development, enhancement, and assessment of its own software.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment and as part of this final rule we have substantially reduced the scope of the final requirements to be fully within the developer of certified health IT's purview, such that the developer will know and be able to fully estimate the resources it will need to expend to maintain complete and up-to-date source attribute information (which could be limited if, for example, the developer does not supply any Predictive DSIs as part of its Health IT Module). We appreciate the comment and as part of this final rule we have substantially reduced the scope of the finalized requirements to be fully within the developer of certified health IT's purview, such that the developer will know and be able to fully estimate the resources it will need to expend to maintain complete and up-to-date source attribute information (which could be limited if, for example, the developer does not supply any Predictive DSIs as part of it Health IT Module). We also believe that this scope and associated information is necessary for the trustworthy use of Predictive DSIs and that the benefits will be commensurate with the burden implied. As stated numerous times throughout the preamble, our intention in requiring such work is to better ensure that high quality Predictive DSIs can be more effectively used to improve patient care.
                    </P>
                    <P>
                        Given the many comments received from interested parties, we have limited the source attributes that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) are required to complete and keep current to those that are related to Predictive DSIs supplied by the developer of certified health IT, which we believe would limit the resources required to gather information from 
                        <E T="03">other parties.</E>
                         We describe in further detail these requirements in subsequent responses in this final rule. We reiterate that Health IT Modules must support the capability for 
                        <E T="03">other party</E>
                         source attribute information to be accessible to users, but that developers are not required to receive or proactively acquire such information for user access from these 
                        <E T="03">other parties</E>
                         just because a user selects (
                        <E T="03">i.e.,</E>
                         activates) a Predictive DSI using the developer's Health IT Module.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters recommended that the requirements should be limited to require summary information of source attributes and only for high-impact Predictive DSI that presents a greater risk of potential harm. One commenter recommended that ONC should take a risk-based approach and limit Predictive DSIs in scope and exclude low-risk use cases for consumers, such as general wellness.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments. However, the Program is not predicated on levels of risk that a technology may pose. As previously noted, we believe that identifying whether a Predictive DSI is “high-risk” or could have a “high-impact” across millions of patients is not appropriate for this rulemaking because Predictive DSIs that may in some sense be “low-risk,” such as those that predict appointment no-shows can (in some cases indirectly) impact the healthcare of millions of individuals and thereby be “high-impact.” We also believe that it is important to require the same information for Predictive DSIs supplied by developers of certified health IT. We reiterate that we have not established requirements for specific measures of validity or fairness, for example. Rather, we encourage industry, academic, professional associations, and other interested parties to determine which information best fits each use case. For instance, a radiological or oncologic society might develop recommendation on how to measure fairness for a Predictive DSI that predicts onset of melanoma in diverse populations, and we encourage the use of those measures as they continue to be refined. We are also aware of ongoing work to standardize approaches to select specific measures and performance targets and encourage developers to follow those best practices.
                        <SU>120</SU>
                        <FTREF/>
                         We believe our requirements at § 170.315(b)(11)(iv)(B) are consistent with industry and academia-developed reporting guidelines, and are appropriately balanced and flexible, while ensuring a consistent baseline of information users need to make informed decisions regarding their use of a Predictive DSI.
                    </P>
                    <FTNT>
                        <P>
                            <SU>120</SU>
                             Health AI Partnership. “Define performance targets,” 
                            <E T="03">https://healthaipartnership.org/guiding-question/define-performance-targets</E>
                             Data Science and Public Policy, Carnegie Mellon University. “Aequitas” 
                            <E T="03">http://www.datasciencepublicpolicy.org/our-work/tools-guides/aequitas/.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concerns that our proposal was duplicative of FDA requirements, noting that they believed our proposal imposes duplicative and unnecessary requirements for software solely based on its use within certified health IT, creating additional burdens for device manufacturers who are also regulated by the FDA. Commenters expressed concern regarding the existing authority that the FDA has over device CDS, which may result in a duplication of efforts with differing requirements, meaning providers and EHR vendors would need to satisfy two sets of regulations. One commenter noted that they believe that in some instances, publication of source attribute information distinct from existing labeling could require supplemental FDA authorization. Some commenters suggested that regulating source attributes would be accomplished more effectively by the FDA.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the concerns expressed by these commenters, which is why we worked closely with the FDA on development of our proposals in § 170.315(b)(11), especially regarding Predictive DSI-specific source attributes. We are aware that technologies that meet the definition for Predictive DSI within the Program may be considered Non-Device CDS, be considered CDS with device software functions, or lie outside of FDA's purview, depending on the specifics of the technology. We worked with the FDA expressly to minimize duplication of effort and maximize alignment across our distinct and different authorities.
                    </P>
                    <P>
                        We coordinated with FDA to ensure that the information required within source attributes in our finalized § 170.315(b)(11) is complementary and not conflicting with the information that FDA describes in its CDS Guidance, finalized in September 2022.
                        <SU>121</SU>
                        <FTREF/>
                         Specifically, we believe that both (1) the 
                        <PRTPAGE P="1263"/>
                        content of the information described for source attributes in § 170.315(b)(11)(iv) and (2) the capabilities required in § 170.315(b)(11)(iii) and § 170.315(b)(11)(v) are complementary and aligned with FDA CDS guidance and could reduce burdens for entities that develop device software functions that also meet the definition of Predictive DSI.
                    </P>
                    <FTNT>
                        <P>
                            <SU>121</SU>
                             See 
                            <E T="03">https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software</E>
                            .
                        </P>
                    </FTNT>
                    <P>We note that section 520I(1)(E) of the Food Drug &amp; Cosmetics (FD&amp;C) Act (Pub. L. 75-717, Jun. 1938) excludes from the definition of “device,” software functions that, among other things, are intended for the purpose of enabling a healthcare professional to independently review the basis for recommendations that such software presents. As part of this alignment effort across both FDA and ONC regulatory requirements, we identified and have finalized source attribute information that could plausibly address some of the informational requirements in 520I(1)(E)(iii) of the FD&amp;C Act, including:</P>
                    <P>
                        • § 170.315(b)(11)(iv)(B)(
                        <E T="03">2</E>
                        ) Purpose of the intervention, including: (
                        <E T="03">i</E>
                        ) Intended use of the intervention; (
                        <E T="03">ii</E>
                        ) Intended patient population(s) for the intervention's use; (
                        <E T="03">iii</E>
                        ) Intended user(s); and (
                        <E T="03">iv</E>
                        ) Intended decision-making role the intervention was designed to be used/for (
                        <E T="03">e.g.,</E>
                         informs, augments, replaces clinical management).
                    </P>
                    <P>
                        • § 170.315(b)(11)(iv)(B)(
                        <E T="03">4</E>
                        ) Intervention development details and input features, including at a minimum: (
                        <E T="03">i</E>
                        ) Exclusion and inclusion criteria that influenced the data set; (
                        <E T="03">ii</E>
                        ) Use of variables in 170.315(b)(11)(iv)(A)
                        <E T="03">(5)-(13)</E>
                         as input features; (
                        <E T="03">iii</E>
                        ) Description of demographic representativeness according to variables in § 170.315(b)(11)(iv)(A)
                        <E T="03">(5)-(13)</E>
                         including, at a minimum, those used as input features in the intervention; and (
                        <E T="03">iv</E>
                        ) Description of relevance of training data to intended deployed setting.
                    </P>
                    <P>
                        • § 170.315(b)(11)(iv)(B)(
                        <E T="03">7</E>
                        ) Quantitative measures of performance, including: (
                        <E T="03">i</E>
                        ) Validity of intervention in test data derived from the same source as the initial training data; and (
                        <E T="03">v</E>
                        ) References to evaluation of use of the intervention on outcomes, if available, including, bibliographic citations or hyperlinks to evaluations of how well the intervention reduced morbidity, mortality, length of stay, or other outcomes.
                    </P>
                    <P>We believe that these similarities will reduce compliance burden in three ways. First, an entity that develops device software functions that also meet the definition of Predictive DSI would be able to fulfill informational requirements for both FDA and ONC purposes using the same or similar information. Second, an entity that develops device software functions that also meet the definition of a Predictive DSI may be eligible to be considered Non-Device CDS according to FDA guidance, if the developer of the Predictive DSI fulfils informational requirements according to Program requirements in § 170.315(b)(11) and § 170.402(b)(4). Specifically, we note that the capability to enable a limited set of identified users to select evidence-based DSIs and Predictive DSIs in § 170.315(b)(11)(iii) and access source attributes for these DSIs in § 170.315(b)(11)(v) could be the technical mechanism by which technologies meet requirements in section 520I(1)(E)(iii) of the FD&amp;C Act, described as Criterion 4 of the FDA CDS guidance. Finally, we believe that burdens will be reduced across entities regulated by FDA and ONC because an entity that develops device software functions that also meet the definition of a Predictive DSI could leverage Program requirements to enable users to select Predictive DSIs in § 170.315(b)(11)(iii) and access source attribute information in § 170.315(b)(11)(v). These capabilities could serve as the technical means to deliver information to users about the credibility of the device software function that is necessary for “independent review,” without having to build a parallel technological means to deliver such information.</P>
                    <P>For example, for those software functions that are considered non-device CDS, and therefore are not the focus of the FDA's regulatory oversight, our source attribute requirements are complementary to the required factor “intended for the purpose of enabling such healthcare professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such healthcare professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient” (section 520I(1)(E)(iii) of the FD&amp;C Act). In this case, our requirements are supportive of meeting aspects which may be part of determining that a Predictive DSI is not a medical device and therefore not the focus of the FDA's oversight.</P>
                    <P>For those CDS software that are medical devices and the focus of the FDA's oversight, we note our requirements are consistent with best practices and recommendations similarly provided by the FDA. In such cases, as these recommendations are consistent across our agencies, we believe that providing such information should not increase burden on developers who may be responsible for meeting both FDA and ONC requirements.</P>
                    <P>We note that our authorities and policy objectives for decision support are not identical to those of the FDA, and so the information required for source attributes may not be identical to the information that would enable independent review according to FDA's guidance and determination, and that the inverse is also true. For instance, we have included source attributes related to the determination of fairness, as well as measures of local validation pursuant to the purposes enumerated in 42 U.S.C. 300jj-11(b)(11) and (4) to support development of a nationwide health information technology infrastructure that improves efforts to reduce health disparities and that provides appropriate information to help guide medical decisions at the time and place of care, respectively, but the FDA CDS guidance did not explicitly describe measures related to fairness or local validation in their description of independent review. We note that a determination regarding information necessary for independent review lies with, and would continue to lie with, the FDA.</P>
                    <P>
                        Beyond the FDA CDS guidance, we note alignment with several categories of source attribute information in the finalized § 170.315(b)(11)(iv)(B) and IRM practices described in § 170.315(b)(11)(vi) across other FDA guidance documents including the FDA's draft guidance on Marketing Submission Recommendations for a Predetermined Change Control Plan for Machine Learning Device Software Functions (PCCP-ML guidance) 
                        <SU>122</SU>
                        <FTREF/>
                         and the FDA's guidance on Content of Premarket Submissions for Device Software Functions. We also note important differences between these requirements and FDA guidance, which highlights our complementary—yet distinct—regulatory authorities. Specifically, we highlight that the source attributes for ongoing maintenance of intervention implementation and use in the finalized § 170.315(b)(11)(iv)(B)(
                        <E T="03">8</E>
                        ) are similar to information described within FDA's PCCP-ML draft guidance. However, specific emphases for fairness measures in local data (at § 170.315(b)(11)(iv)(B)(
                        <E T="03">8</E>
                        )(
                        <E T="03">iv</E>
                        )) and 
                        <PRTPAGE P="1264"/>
                        descriptions of the frequency by which the intervention's performance is corrected when risks related to validity and fairness are identified (at § 170.315(b)(11)(iv)(B)(
                        <E T="03">9</E>
                        )(
                        <E T="03">ii</E>
                        )) are not requirements of the FDA's PCCP-ML draft guidance. We also note that our source attribute information pertains to an expanded set of technologies because it is not limited to Predictive DSI that are unlocked or those that developers intend to modify over time. Our scope for technology that meets the definition of Predictive DSI is more expansive than what the PCCP-ML guidance considers because we view transparency into the performance of Predictive DSIs in a local health system or clinic to be particularly important to users to determine if a given Predictive DSI is fit for use on or with their patients, particularly in the case of older Predictive DSI that are rarely retrained based on local data. We believe that ensuring certified health IT has a place to provide this information, or indicate its omission, will be of value to users deciding on whether a technology is fit-for-purpose at their organization, but may be beyond the scope of FDA's review and approval process.
                    </P>
                    <FTNT>
                        <P>
                            <SU>122</SU>
                             See 
                            <E T="03">https://www.fda.gov/regulatory-information/search-fda-guidance-documents/marketing-submission-recommendations-predetermined-change-control-plan-artificial</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        Similar examples exist in what FDA describes in its Premarket Submissions for Device Software Functions guidance, including documentation recommendations related to “software description,” which align with ONC final requirements in § 170.315(b)(11)(iv)(B)(
                        <E T="03">1</E>
                        ) for details and output of the intervention and § 170.315(b)(11)(iv)(B)(
                        <E T="03">4</E>
                        ) for intervention development details and input features, as well as FDA guidance for a “risk management file,” which aligns with requirements in § 170.523(f)(1)(xxi) for summary risk management information to be available via publicly accessible hyperlink. We believe that these similarities will reduce the burden on complying with our Program requirements for those Predictive DSI that have device software functions.
                    </P>
                    <P>We are aware that some Predictive DSI may not be within FDA's purview because, consistent with the history of our Program, we have not focused requirements for DSIs on specific use cases. Thus, we believe that ONC is well positioned to regulate certified health IT in ways that are different from how FDA regulates device software functions and disagree with commenters' suggestion that more effective regulation of source attributes could be accomplished by the FDA, or that there is conflict between FDA labeling requirements and source attributes, because we have different authorities and, where similar requirements may be needed within these differing scopes, our agencies have worked closely to ensure complementary recommendations and requirements. These technologies, especially in the aggregate, impact how healthcare is delivered, and we believe our complementary authorities will provide important benefits to users.</P>
                    <P>
                        <E T="03">Comment.</E>
                         Several commenters expressed concern that the list of required source attributes that must be disclosed is overly broad and potentially impractical to implement. Commenters requested clarity regarding how DSI developers would satisfy the proposed requirement of providing access of source attributes to an end user and how that information would need to be presented or formatted. They further noted the concern that providing access to users of such broad source attribute information could result in an interface that impairs physician usability. Another commenter suggested that the health IT developers should be required to instead provide a configuration option through which third-party vendors of Predictive DSI could include their source attributes during the integration with health IT or implementation within a hospitals or provider's database. Another commenter suggested that the health IT developers should be required to instead provide a configuration option through which third-party vendors of Predictive DSI could include their source attributes during the integration with health IT or implementation within a hospitals or provider's database.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate comments regarding implementation of our source attributes requirements for user review and implications for usability. While our proposals required a Health IT Module to enable users to review source attribute information, we did not specify either that a user must review source attribute information or that source attribute information be presented at a specific time or manner to a user. We noted in the HTI-1 Proposed Rule that we understood that source attribute information may be presented in varied ways at various points of workflow and contain varying levels of detail and do not intend to limit the options by which this information can be made available (88 FR 23788). We also said, consistent with prior ONC discussion related to existing § 170.315(a)(9)(v) requirements for source attributes (77 FR 54215), the proposal would not require the automatic display of source attributes information when a recommendation, alert, or other decision support output is presented that resulted from a DSI (88 FR 23788). Last, we noted that we were not aware of widely agreed upon best practices for the format in which this source attribute information should be displayed. However, we are aware of industry efforts to standardize a format to display information about technology in the form of a “model card” or “nutritional label” for healthcare (88 FR 23794). We believe that rather than prescribing uniform presentation of this kind of information, that developers of certified health IT should work with their customers to determine the best format and structure of source attribute information. Finally, we note that we did not prescribe a mechanism, standard, or process for how developers of certified health IT should receive or acquire information from 
                        <E T="03">other parties</E>
                         for source attributes in the HTI-1 Proposed Rule and have also not done so in this final rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concern that our proposal would require health IT developers with certified health IT to regulate other developer's Predictive DSI and stated that health IT developers should not be responsible for the Predictive DSI of their customers or 
                        <E T="03">other parties</E>
                         and that health IT developers' certification should not be contingent on 
                        <E T="03">other parties</E>
                         providing information to the developer.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their concerns. As described elsewhere in this final rule, we have adopted modified final rule requirements and a reduced scope to address these concerns. Specifically, we have finalized a different scope with respect to 
                        <E T="03">other party</E>
                         source attributes, such that developers of certified Health IT are only required to make source attribute information available when the health IT developer supplies the 
                        <E T="03">other party's</E>
                         Predictive DSI as part of its Health IT Module. In alignment with the comments, the finalized requirements of § 170.315(b)(11) do not extend to developers of certified health IT being accountable for Predictive DSIs developed by their customers or 
                        <E T="03">other party</E>
                         Predictive DSIs implemented by their customers.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern that the proposal will not be effective at creating broad, uniform transparency throughout the Predictive DSI marketplace because ONC has authority to regulate certified health IT, which is only a portion of the predictive model marketplace. The commenter noted that the proposal would create imbalance in the marketplace between developers of certified health IT and developers of noncertified health IT. The commenter also stated that 
                        <PRTPAGE P="1265"/>
                        information from third-party developers will be inconsistent and intermittent.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We believe that the scope of our definition for Predictive DSI and our requirements for Predictive DSIs supplied by developers of certified health IT are sufficiently calibrated to affect a substantial portion of the DSI marketplace and that developers of certified health IT are well-positioned to ensure that information is updated routinely and consistently for Predictive DSI they supply as part of their health IT.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern that our proposals would result in inefficiencies for developers, and that transparency goals would be more efficiently achieved through regulations that directly apply to creators of clinical decision alert content. They noted that in some cases that would be those developing EHRs, but in most instances, those creating alerts are either third-party businesses or health care providers themselves.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree with the commenter that there is a growing market for DSIs created by 
                        <E T="03">other parties,</E>
                         which could include third-party businesses or health care providers using certified health IT. While we have not finalized our proposals to require developers of certified health IT to indicate when source attributes are missing for all 
                        <E T="03">other party</E>
                        -developed Predictive DSIs, we have finalized that a developer of certified health IT must complete and keep current descriptions of source attribute information as specified in § 170.402 (b)(4) for all interventions supplied by the health IT developer, including 
                        <E T="03">other party</E>
                         interventions the health IT developer supplies as part of its Health IT Module. We believe this scope appropriately focuses on what a developer of certified health IT can readily and efficiently access in terms of source attribute information. We also finalize that for source attributes in § 170.315(b)(11)(iv)(B)(
                        <E T="03">6</E>
                        ); (b)(11)(iv)(B)(
                        <E T="03">7</E>
                        )(
                        <E T="03">iii</E>
                        ), (
                        <E T="03">iv</E>
                        ), and (
                        <E T="03">v</E>
                        ); (b)(11)(iv)(B)(
                        <E T="03">8</E>
                        )(
                        <E T="03">ii</E>
                        ) and (
                        <E T="03">iv</E>
                        ); and (b)(11)(iv)(B)(
                        <E T="03">9</E>
                        ) a health IT developer must indicate when information is not available for review. This requirement pertains to both source attributes related to Predictive DSIs authored by the developer of certified health IT and to Predictive DSIs developed by 
                        <E T="03">other parties</E>
                         that are supplied by the developer as part of its Health IT Module.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Numerous commenters requested that we clarify that the certification requirements for developers of certified health IT do not convey an obligation for health care providers to review all the source attributes of a DSI each time they choose to use a tool.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Nothing in our proposals nor this final rule would compel a user of certified health IT to review source attributes. However, we note it would be a best practice for users to conduct such affirmative reviews in an effort to identify potentially discriminatory tools, as discriminatory outcomes may violate applicable civil rights law.
                        <SU>123</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>123</SU>
                             See U.S. Dept of Health &amp; Human Servs., Office for Civil Rights, Notice of Proposed Rulemaking, Nondiscrimination in Health Programs and Activities, 87 FR 47824, 47880 (Aug. 4, 2022), 
                            <E T="03">https://www.federalregister.gov/documents/2022/08/04/202216217/nondiscrimination-in-health-programs-and-activities</E>
                             (prohibiting discrimination on the basis of race, color, national origin (including limited English proficiency), sex (including sexual orientation and gender identity), age, or disability in certain health programs or activities 
                            <E T="03">through the use of clinical algorithms in their decisionmaking</E>
                            ); Title VI of the Civil Rights Act of 1964, 42 U.S.C. 2000d 
                            <E T="03">et seq.</E>
                             (prohibiting discrimination on the basis of race, color, or national origin (including limited English proficiency) in federally funded programs or activities); Title IX of the Education Amendments of 1972, 20 U.S.C. 1681 
                            <E T="03">et seq.</E>
                             (prohibiting sex discrimination in federally funded education programs or activities); the Age Discrimination Act of 1975, 42 U.S.C. 6101 
                            <E T="03">et seq.</E>
                             (prohibiting age discrimination in federally funded programs or activities); Section 504 of the Rehabilitation Act of 1973, 29 U.S.C. 794 (prohibiting disability discrimination in federally funded or federally conducted programs or activities); and the Americans with Disabilities Act, 42 U.S.C. 12101 
                            <E T="03">et seq.</E>
                             (prohibiting disability discrimination by employers, state and local government entities, and businesses that are open to the public, among others).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concern that our proposal for source attributes for Predictive DSIs is overly broad and should instead be narrowed to specifically focus on AI and machine learning algorithms, noting that there are substantial risks of bias associated with these models if they are not constructed in a manner that allows the end user to understand how they were constructed and will be maintained going forward.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments and agree that bias associated with AI and machine learning algorithms could create substantial risks if they are presented to the end user without information to understand how they were constructed, evaluated, and should be maintained. We believe that recent scrutiny of other predictive models has shown that those models can similarly present substantial risk if presented without this information. We note that most of our source attributes are specific to Predictive DSIs, which encompasses AI and machine learning algorithms. We have only amended existing requirements for evidence-based DSIs by asking for specific data elements to be identified when used by the DSI, including race, ethnicity, language, sexual orientation, gender identity, sex, date of birth, SDOH, sexual orientation, and health assessments data elements (
                        <E T="03">e.g.,</E>
                         disability status).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters applauded HHS's efforts to recognize the challenges of complex predictive models and the general need for public disclosure of source data to determine reliability. Commenters also encouraged HHS to consider additional measures to oversee the explain-ability of the data output and for HHS to adopt broad policies that ensure public access to both models and their data sources. One commenter stated that they believed that the information presented under “source attributes” should be in the public domain and not just presented to end users, and information about which datasets were used to train and evaluate a DSI should be in the public domain and added to the required “source attributes.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support. However, we decline to consider additional measures regarding the concept of “explain-ability,” at this time and instead we include a requirement for risks related to intelligibility to be analyzed and mitigated at § 170.315(b)(11)(vi). We also appreciate the feedback regarding the value of making public the information we are requiring for source attributes. We view access to source attribute information as a necessary step for users of Predictive DSIs to determine the quality of Predictive DSIs they use. We decline to require public disclosure of source attribute information at this time. Rather, we believe that it is vital to implement the policies that we have finalized in this rule, learn from their implementation, and revisit ways to improve transparency over time. As the industry as a whole gains experience with making source attributes available to users of Predictive DSIs, we may consider broader and public availability of source attribute information in future rulemakings.
                    </P>
                    <P>
                        Meanwhile, we remind interested parties that under current Program requirements related to the Communications Condition and Maintenance of Certification requirements in § 170.403 users have explicit rights to discuss publicly various aspects regarding the performance of certified health IT. Specifically, we note that in § 170.403(a)(1)(iv) users have the right to describe relevant information regarding their experiences when using a Health IT Module. We also noted in 
                        <PRTPAGE P="1266"/>
                        the ONC Cures Act Final Rule that algorithms would be considered “non-user-facing aspects of health IT” as they are not readily apparent to persons using health IT for the purpose for which it was purchased or obtained (85 FR 25731). Thus, communications regarding algorithms (
                        <E T="03">e.g.,</E>
                         mathematical methods and logic) could be restricted or prohibited, while communications regarding the output of the algorithm and how it is displayed in a health IT system could not be restricted as “non-user-facing aspects of health IT.” Given this, we note that source attribute information is user-facing and is relevant to a user's experience using certified health IT. Thus, source attribute information is among the kinds of information that customers may freely discuss publicly.
                    </P>
                    <P>
                        We also note our discussion in the HTI-1 Proposed Rule regarding an individual's ability to obtain information about any use of a Predictive DSI—or other emerging technologies—in their healthcare through the HIPAA Privacy Rule individual's right of access (88 FR 23795).
                        <SU>124</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>124</SU>
                             45 CFR 164.524.
                        </P>
                    </FTNT>
                    <P>
                        In many cases, developers of certified health IT serve as HIPAA business associates to their covered entity customers, such as health care providers or health plans.
                        <SU>125</SU>
                        <FTREF/>
                         If an individual requests access to their health information from a HIPAA covered entity (
                        <E T="03">e.g.,</E>
                         a health care provider that transmits health information in electronic form in connection with an HHS adopted standard transaction) that individual, generally, has a right to access medical and health information (protected health information (PHI)) about themselves in one or more designated record sets (DRS) maintained by or for the individual's HIPAA covered entity.
                        <SU>126</SU>
                        <FTREF/>
                         The DRS could include underlying data and information used to generate recommendations about an individual's healthcare, such as information about the use of a Predictive DSI in a healthcare decision and source attribute information associated with use of a Predictive DSI in a healthcare decision.
                        <SU>127</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>125</SU>
                             See definitions of “business associate” and “covered entity” at 45 CFR 160.103.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>126</SU>
                             For more information about the HIPAA Privacy Rule individual's right of access, see OCR's HIPAA Access Guidance: 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>127</SU>
                             See, 
                            <E T="03">e.g.,</E>
                             OCR's HIPAA FAQs 2048 and 2049, 
                            <E T="03">https://www.hhs.gov/guidance/document/faq-2048-does-individual-have-right-access-genomic-information-generated-clinical; https://www.hhs.gov/hipaa/for-professionals/faq/2049/does-an-individual-have-a-right-under/index.html#:~:text=Under%20the%20HIPAA%20Privacy%20Rule,a%20clinical%20laboratory%20may%20hold.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter agreed that developers should implement practices and processes when a model's performance is inconsistent with its intended use and recommended that we include in regulations a specific process for developers to follow. Another commenter recommended including “identification of intended user qualifications.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree with commenters that developers should implement processes to update models and have included relevant source attributes describing the process of updating models at § 170.315(b)(11)(iv)(B)(
                        <E T="03">8</E>
                        ) and (
                        <E T="03">9</E>
                        ). However, we decline to specify a process by which this is performed because it is likely to vary across Predictive DSI. Information on intended user qualifications would be appropriately included at § 170.315(b)(11)(iv)(B)(
                        <E T="03">2</E>
                        )(
                        <E T="03">iii</E>
                        ) “intended users,” but we do not explicitly require such information to be there.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested that DSIs based on studies or recommendations from Federal Agencies should be exempt from any other reporting requirements other than identifying the Agency and the study.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We decline to exempt any DSIs described in § 170.315(b)(11) from any of the applicable reporting requirements based on where the recommendations originate. We believe that recommendations from a federal agency, such as the Centers for Disease Control and Prevention, should include all the source attributes, not only the bibliographic citation, as is suggested by the commenter. For the same reason that transparency would be helpful for any evidence-based DSI, so too would transparency be valuable for DSIs based on studies or recommendations from federal agencies.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Numerous commenters supported the FAVES framework described in the HTI-1 Proposed Rule, noting that these concepts reflect a consensus view of the characteristics of high-quality Predictive DSIs. One commenter expressed concern that the effectiveness in regulating source attributes would be hampered by reliance on highly defined input fields which can be made subject to political analysis (
                        <E T="03">e.g.,</E>
                         FAVES) and related noncomputational tests to guide to desired political outcomes, and instead suggested that ONC, rather than focusing on redesign of models and model parameters, instead emphasize transparency as to when an AI algorithm is being used.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the many statements of support for our framing of “high-quality,” predictive algorithms to mean that such algorithms are fair, appropriate, valid, effective, and safe, or FAVES. However, we do not believe a Program requirement for Health IT Modules to indicate when an AI algorithm was used to support decision-making is appropriate (as users should already understand if they're using a predictive AI to support their decision-making) nor sufficient for users to understand the quality of such AI algorithms. We believe that defined source attribute categories, coupled with a description of the characteristics that make up a high-quality Predictive DSI, are necessary to provide consistent information that will more effectively promote the use of those Predictive DSI where appropriate. Further, we note that while we have defined input fields, we have not established requirements for specific measures or identified specific thresholds for content that is related to those categories.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters encouraged ONC to work with interested parties to further develop guidance and standards. Specifically, one commenter urged ONC and HHS to convene interested parties to develop a consensus set of meta-data that should and, must be, transparently provided by DSI developers, and strongly supported ONC requiring a standard representing a Structure Product Label for Predictive Decision Support. One commenter encouraged additional regulatory parameters and encouraged ONC to consider requirements for regular, algorithmic impact assessments that analyze data sets, biases, and how users interact with the systems, and the overall design and monitoring of system outputs, as well as to include expressly incorporating data-set best practices and data standards requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments and will continue to collaborate with interested parties inside and outside of government to ensure that information resulting from our transparency requirements is meaningful for patient care and decision-making.
                    </P>
                    <P>
                        Given the comments received from a range of interested parties, and to clarify the scope of information required for an applicable Predictive DSI, we have finalized our proposals in § 170.315(b)(11)(iv)(B) with modification. We note that the information required here as source attribute information is similar to the “meta-data” described by commenters. 
                        <PRTPAGE P="1267"/>
                        First, rather than include references to evidence-based source attributes as proposed, we have added new subparagraphs as part of the “Intervention details” source attribute at § 170.315(b)(11)(iv)(B)(
                        <E T="03">1</E>
                        ) to include similar general attribute information. Specifically, at § 170.315(b)(11)(iv)(B)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) we require “The name and contact information for the developer of the intervention,” and at § 170.315(b)(11)(iv)(B)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ) we require “Funding source of the intervention,” which are substantially similar to the proposed inclusion of bibliographic information (since citations include the name and contact information for corresponding authors) and “developer of the intervention and “Funding source of the intervention” is directly parallel to “Funding source of the intervention development technical implementation” all of which we proposed to apply to Predictive DSIs in the HTI-1 Proposed Rule. Commenters noted, and we agree, that bibliographic citation of the intervention finalized at § 170.315(b)(11)(iv)(A)(
                        <E T="03">1</E>
                        ) likely would not be relevant for all Predictive DSIs and other source attributes specific to evidence-based DSIs at § 170.315(b)(11)(iv)(A) were duplicative of source attributes in § 170.315(b)(11)(iv)(B).
                    </P>
                    <P>Second, we have made explicit in regulation text several requirements described in the HTI-1 Proposed Rule's preamble to ensure that health IT developers clearly understand the source attribute requirements applicable to Health IT Modules presented for certification to § 170.315(b)(11). We have finalized these requirements to address many commenters' concerns regarding proprietary information and to help convey at what level of detail Predictive DSI source attributes should be available for a limited set of identified users to record, change, and access.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received numerous comments from interested parties indicating that more clarity was needed to help communicate the scope and detail of information included as source attributes in what is now finalized at § 170.315(b)(11)(iv)(B).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree and have finalized regulation text at § 170.315(b)(11)(iv)(B) to clarify the scope and detail of information required to be available for user review. We note that these explicit requirements in regulation text mirror the requirements described previously in preamble or represent a subset of requirements previously described in preamble. We also reiterate our preamble discussion that the requirements do not require disclosing or sharing IP or proprietary information existing in the developer's health IT, including 
                        <E T="03">other parties'</E>
                         IP and proprietary information.
                    </P>
                    <HD SOURCE="HD3">Intervention Details</HD>
                    <P>
                        We proposed three source attributes related to details of predictive models and their proper use in § 170.315(b)(11)(vi)(C)(
                        <E T="03">1</E>
                        ) “Intervention Details,” Including “Output of the intervention,” “Intended use of the intervention,” and “Cautioned out-of-scope use of the intervention.” We refer readers to 88 FR 23789-23790 for a detailed discussion of our proposed rationale for these source attributes as well as examples and additional instruction, which we have made explicit in the regulation text below.
                    </P>
                    <P>
                        We have finalized § 170.315(b)(11)(iv)(B)
                        <E T="03">(1)</E>
                         as follows: “Details and output of the intervention, including: 
                        <E T="03">(i)</E>
                         Name and contact information for the intervention developer; 
                        <E T="03">(ii)</E>
                         Funding source of the technical implementation for the intervention(s) development (for which we have modified the wording order from the HTI-1 Proposed Rule to make the source attribute read clearer and we have also made this corresponding change for evidence-based DSIs as well); 
                        <E T="03">(iii)</E>
                         Description of value that the intervention produces as an output; and 
                        <E T="03">(iv)</E>
                         Whether the intervention output is a prediction, classification, recommendation, evaluation, analysis, or other type of output.”
                    </P>
                    <P>
                        We have finalized § 170.315(b)(11)(iv)(B)
                        <E T="03">(2)</E>
                         “Purpose of the intervention, including: 
                        <E T="03">(i)</E>
                         Intended use of the intervention; 
                        <E T="03">(ii)</E>
                         Intended patient population(s) for the intervention's use; 
                        <E T="03">(iii)</E>
                         Intended user(s); and 
                        <E T="03">(iv)</E>
                         Intended decision-making role for which the intervention was designed to be used/for (
                        <E T="03">e.g.,</E>
                         informs, augments, replaces clinical management).”
                    </P>
                    <P>
                        We have finalized § 170.315(b)(11)(iv)(B)
                        <E T="03">(3)</E>
                         as follows “Cautioned out-of-scope use of the intervention, including: 
                        <E T="03">(i)</E>
                         Description of tasks, situations, or populations where a user is cautioned against applying the intervention; 
                        <E T="03">(ii)</E>
                         and Known risks, inappropriate settings, inappropriate uses, or known limitations.”
                    </P>
                    <HD SOURCE="HD3">Intervention Development</HD>
                    <P>
                        We proposed at 88 FR 23790 three source attributes related to model development in § 170.315(b)(11)(vi)(C)(
                        <E T="03">2</E>
                        ), “Intervention Development,” including “Input features of the intervention including description of training and test data,” “Process used to ensure fairness in development of the intervention,” and “External validation process, if available.” We refer readers to 88 FR 23790-23795 for a detailed discussion of these source attributes in the HTI-1 Proposed Rule.
                    </P>
                    <P>
                        We have finalized § 170.315(b)(11)(iv)(B)
                        <E T="03">(4)</E>
                         as follows “Intervention development details and input features, including at a minimum: 
                        <E T="03">(i)</E>
                         Exclusion and inclusion criteria that influenced the data set; 
                        <E T="03">(ii)</E>
                         Use of variables in 170.315(b)(11)(v)(A)
                        <E T="03">(5)-(13)</E>
                         as input features; 
                        <E T="03">(iii)</E>
                         Description of demographic representativeness according to variables in § 170.315(b)(11)(iv)(A)
                        <E T="03">(5)-(13)</E>
                         including, at a minimum, those used as input features in the intervention; and 
                        <E T="03">(iv)</E>
                         Description of relevance of training data to intended deployed setting.”
                    </P>
                    <P>
                        We have finalized § 170.315(b)(11)(iv)(B)
                        <E T="03">(5)</E>
                         as follows “Process used to ensure fairness in development of the intervention, including: 
                        <E T="03">(i)</E>
                         Description of the approach the intervention developer has taken to ensure that the intervention's output is fair; and 
                        <E T="03">(ii)</E>
                         Description of approaches to manage, reduce, or eliminate bias.”
                    </P>
                    <P>
                        We have finalized § 170.315(b)(11)(iv)(B)
                        <E T="03">(6)</E>
                         as follows “External validation process including: 
                        <E T="03">(i)</E>
                         Description of the source, clinical setting, or environment where an intervention's validity and fairness has been assessed, other than the source training and testing data; 
                        <E T="03">(ii)</E>
                         Party that conducted the external testing; Description of demographic representativeness of external data according to variables in § 170.315(b)(11)(iv)(A)
                        <E T="03">(5)-(13)</E>
                         including, at a minimum, those used as input features in the intervention; and Description of external validation process.”
                    </P>
                    <HD SOURCE="HD3">Quantitative Measures of Intervention Performance</HD>
                    <P>
                        We proposed at 88 FR 23791-23792, five source attributes relevant to validation or evaluation of the performance (including accuracy, validity, and fairness) of the predictive model and evaluation of its effectiveness in § 170.315(b)(11)(vi)(C)(
                        <E T="03">3</E>
                        ) “Quantitative measures of Intervention Performance,” including “Validity of prediction in test data,” “Fairness of prediction in test data,” “Validity of prediction in external data, if available,” “Fairness of prediction in external data, if available,” and “References to evaluation of use of the model on outcomes, if available.” Together, these source attributes were intended to be a presentation of the 
                        <PRTPAGE P="1268"/>
                        measure or set of measures related to the model's validity (often referred to as performance) and fairness when tested in data derived from the same source as the initial training data as well as when tested in data external to—that is, from a different source than—the primary training data. “References to evaluation of use of the model on outcomes, if available,” are bibliographic citations or links to evaluations of how well the intervention, or model on which it is based accomplished specific objectives such as reduced morbidity, mortality, length of stay or other important outcomes.
                    </P>
                    <P>
                        We have finalized § 170.315(b)(11)(iv)(B)(
                        <E T="03">7</E>
                        ) as follows “Quantitative measures of performance, including: 
                        <E T="03">(i)</E>
                         Validity of intervention in test data derived from the same source as the initial training data; 
                        <E T="03">(ii)</E>
                         Fairness of intervention in test data derived from the same source as the initial training data; 
                        <E T="03">(iii)</E>
                         Validity of intervention in data external to or from a different source than the initial training data; 
                        <E T="03">(iv)</E>
                         Fairness of intervention in data external to or from a different source than the initial training data; and 
                        <E T="03">(v)</E>
                         References to evaluation of use of the intervention on outcomes, including, bibliographic citations or hyperlinks to evaluations of how well the intervention reduced morbidity, mortality, length of stay, or other important outcomes.”
                    </P>
                    <HD SOURCE="HD3">Ongoing Maintenance of Intervention Implementation and Use</HD>
                    <P>At 88 FR 23792, we proposed three source attributes related to the “ongoing maintenance of intervention implementation and use,” including, “Update and continued validation or fairness assessment schedule,” “Validity of prediction in local data, if available,” and “Fairness of prediction in local data, if available.” These source attributes were a description of the process and frequency by which the model's performance is measured and monitored in the local environment and corrected when risks related to validity and fairness are identified.</P>
                    <P>
                        We have finalized § 170.315(b)(11)(iv)(B)
                        <E T="03">(8)</E>
                         as follows “Ongoing maintenance of intervention implementation and use, including: 
                        <E T="03">(i)</E>
                         Description of the process and frequency by which the intervention's validity is monitored over time; 
                        <E T="03">(ii)</E>
                         Validity of intervention in local data; 
                        <E T="03">(iii)</E>
                         Description of the process and frequency by which the intervention's fairness is monitored over time; and 
                        <E T="03">(iv)</E>
                         Fairness of intervention in local data.”
                    </P>
                    <HD SOURCE="HD3">Update and Continued Validation or Fairness Assessment Schedule</HD>
                    <P>
                        At 88 FR 23792 we proposed a source attribute, “
                        <E T="03">Update and continued validation or fairness assessment schedule</E>
                        ” and described it as including “the process and frequency by which the model's performance is measured and monitored in the local environment and corrected when risks related to validity and fairness are identified.” Information from this attribute is important to assess whether the model is up to date or may reflect outdated trends.
                    </P>
                    <P>
                        We have finalized § 170.315(b)(11)(iv)(B)(
                        <E T="03">9</E>
                        ) as follows “Update and continued validation or fairness assessment schedule, including: 
                        <E T="03">(i)</E>
                         Description of process and frequency by which the intervention is updated; and 
                        <E T="03">(ii)</E>
                         Description of frequency by which the intervention's performance is corrected when risks related to validity and fairness are identified.”
                    </P>
                    <HD SOURCE="HD3">ix. Missing Source Attribute Information</HD>
                    <P>
                        At 88 FR 23795-23796 we proposed that a Health IT Module certified § 170.315(b)(11) would need to clearly indicate when a source attribute listed is not available for the user to review, including in two specific circumstances. First, we proposed that for source attributes that include the “if available” phrase, a Health IT Module must clearly indicate when such source attribute is not available for review. Second, we proposed that when a Health IT Module enables or interfaces with a DSI developed by 
                        <E T="03">other parties</E>
                         that are not developers of certified health IT, that Health IT Module must clearly indicate when any source attribute is not available for the user to review. We explained that this meant that a Health IT Module that supports a DSI developed by 
                        <E T="03">other parties</E>
                         that are not developers of certified health IT would have needed to clearly indicate when any attribute listed is not available for the user to review, regardless of whether the DSI is a Predictive DSI, as defined at § 170.102, or an evidence-based DSI.
                    </P>
                    <P>
                        At 88 FR 23796, we clarified that “
                        <E T="03">other parties,</E>
                        ” as used in our proposal, included any party that develops a DSI, a model, or an algorithm that is used by a DSI and is not a developer of certified health IT. These could include, but were not limited to: a customer of the developer of certified health IT, such as an individual health care provider, provider group, hospital, health system, academic medical center, or integrated delivery network; a third-party software developer, such as those that publish or sell medical content or literature used by a DSI; or researchers and data scientists, such as those who develop a model or algorithm that is used by a DSI.
                    </P>
                    <P>
                        We reiterated that while we did not prescribe how a certified Health IT Module would need to indicate that an attribute was missing that the certified Health IT Module would need to communicate an attribute was missing unambiguously and in a conspicuous manner to a user. We noted that these “
                        <E T="03">other parties</E>
                        ” may or may not have a contractual relationship with the developer of certified health IT. However, we sought comment on whether we should require developers of certified health IT with Health IT Modules that enable or interface with Predictive DSIs to display source attributes for 
                        <E T="03">other parties</E>
                         with which the developer of certified health IT has a contractual relationship.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received mixed comments supporting and opposing our proposal to require a Health IT Module to clearly indicate when a source attribute is not available for the user to review. Among those who opposed our proposal, they conveyed that indicating to a user when a source attribute was unavailable would create burdens on health IT developers who do not readily have access to source attribute information and would position health IT developers to enforce information gathering requirements on other companies, including third-party vendors with which the health IT developer has no formal contract and health IT customers that create clinical decision support data. Many commenters who opposed this proposal supported an alternative requirement that would require certified developers to (1) provide source attributes and indicate when information was missing for those interventions they themselves authored (
                        <E T="03">i.e.,</E>
                         self-developed interventions) and (2) for those interventions that were developed by 
                        <E T="03">other parties</E>
                         with which the developer of certified health IT worked to implement into their Health IT Modules as opposed to all 
                        <E T="03">other parties,</E>
                         regardless of the health IT developer's relationship with those 
                        <E T="03">other parties.</E>
                         In other words, commenters suggested limiting the transparency requirement to those other parties the health IT developer has a contractual relationship with or to require health IT developers to include functionality to display the information and letting their customers decide whether to display information about their own Predictive DSI or that of other developers with whom the customers have a contractual relationship.
                        <PRTPAGE P="1269"/>
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their concerns. We agree with commenters regarding the burden and implementation issues associated with identifying missing information as we proposed and have made changes to the scope in response. In particular, we have addressed the concerns raised about Predictive DSIs developed by 
                        <E T="03">other parties</E>
                         with which the developer of certified health IT has no formal relationship. The finalized policy, described below more closely aligns with the commenters' alternative policy, which we believe addresses these concerns.
                    </P>
                    <P>
                        While we noted in the HTI-1 Proposed Rule that missing source attribute information would be foundational for users' understanding of the DSI regardless of whether the intervention developer was a developer of certified health IT, a customer of the developer of certified health IT, an academic health system, integrated delivery network, a third-party software developer, or 
                        <E T="03">other party</E>
                         (88 FR 23795), we also acknowledged that we understood there may be circumstances where a developer of certified health IT may not have information pertaining to a source attribute for a Health IT Module to enable such user review.
                    </P>
                    <P>
                        In response to public comments received, we have made two overall adjustments. First, we did not finalize our proposals for missing source attributes as it relates to 
                        <E T="03">other parties</E>
                         as proposed. This is because, as discussed elsewhere in this section, we have constrained the overall scope of the certification criterion and the developer of the certified Health IT Module's accountability to those Predictive DSIs supplied by the health IT developer as part of its Health IT Module. As a result, in circumstances where a developer of certified health IT has not supplied an 
                        <E T="03">other party's</E>
                         Predictive DSI as part of its Health IT Module the developer is not accountable for the unavailability of those Predictive DSI's source attribute information. Second, we have finalized a certification requirement for Health IT Modules to indicate when information is not available for specific source attributes only. Specifically, we have finalized at § 170.315(b)(11)(v)(A)(
                        <E T="03">2</E>
                        ) requirements that for Predictive DSIs, a Health IT Module must indicate when information is not available for review for source attributes in § 170.315(b)(11)(iv)(B)(
                        <E T="03">6</E>
                        ); (b)(11)(iv)(B)(
                        <E T="03">7</E>
                        )(
                        <E T="03">iii</E>
                        ), (
                        <E T="03">iv</E>
                        ), and (
                        <E T="03">v</E>
                        ); (b)(11)(iv)(B)(
                        <E T="03">8</E>
                        )(
                        <E T="03">ii</E>
                        ) and (
                        <E T="03">iv</E>
                        ); and (b)(11)(iv)(B)(
                        <E T="03">9</E>
                        ). We note that the implication of this finalized policy is twofold: (1) developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) must enable a limited set of identified users to access complete and up-to-date plain language descriptions for all source attributes, except those listed in § 170.315(b)(11)(v)(A)(
                        <E T="03">2</E>
                        ); and (2) developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) must enable such access for evidence-based and Predictive DSIs at least when those DSIs are supplied by the health IT developer as part of its Health IT Module.
                    </P>
                    <P>
                        We are aware that, in some limited circumstances, information for specific source attributes related to Predictive DSIs supplied by the health IT developer as part of its Health IT Module may not be available nor re-creatable. For example, health IT developers that supply Predictive DSIs that use models provided through the peer reviewed literature, such as ASCVD, eGFR, APACHE IV, and LACE+ models referenced elsewhere in this final rule,
                        <SU>128</SU>
                        <FTREF/>
                         may not have access to training data that would allow them to: 1) provide a description of demographic representativeness of the training data (§ 170.315(b)(11)(iv)(B)(
                        <E T="03">4</E>
                        )(
                        <E T="03">iii</E>
                        )); 2) generate measures of validity in test data derived from the same source as the initial training data (§ 170.315(b)(11)(iv)(B)(
                        <E T="03">7</E>
                        )(
                        <E T="03">i</E>
                        )); and 3) generate measures of fairness in test data derived from the same source as the initial training data (§ 170.315(b)(11)(iv)(B)(
                        <E T="03">7</E>
                        )(
                        <E T="03">ii</E>
                        )). In cases where information is only available through published literature, developers may provide information for these source attributes that indicate that the relevant information is not available and that it cannot be replicated. In these cases, we encourage organizations to perform external validation of these models and we believe that providing users information on the results of that work will be of high value. We note that where source attribute information is available for Predictive DSIs in these scenarios, or where source attribute information can be extrapolated from the literature (
                        <E T="03">e.g.,</E>
                         intended use, cautioned out-of-scope use, or intended population, etc.) source attribute information should be accessible and modifiable consistent with requirements in § 170.315(b)(11)(v).
                    </P>
                    <FTNT>
                        <P>
                            <SU>128</SU>
                             Goff Jr, David C., et al. “2013 ACC/AHA guideline on the assessment of cardiovascular risk: a report of the American College of Cardiology/American Heart Association Task Force on Practice Guidelines.” 
                            <E T="03">Circulation</E>
                             129.25_suppl_2 (2014): S49-S73.
                        </P>
                        <P>
                            Levey, Andrew S., et al. “A more accurate method to estimate glomerular filtration rate from serum creatinine: a new prediction equation.” 
                            <E T="03">Annals of internal medicine</E>
                             130.6 (1999): 461-470.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters that expressed support for this proposal commended our efforts and requested we strengthen this provision to require that all source attribute information is available for user review. Some commenters expressed support for the proposal stating that it would send a signal to health care providers about the trustworthiness of a DSI tool and encourage AI developers to be transparent. One commenter expressed concern that our proposal would allow health IT developers to opt-out of reporting information and allowing developers to indicate when source attributes are missing should be the exception and not the rule. Another commenter expressed concern that this provision places no limits on how much or what type of data can be missing while still complying with source data transparency requirements and could incentivize developers to not provide any data that might show bias or lead to any type of negative conclusion by potential users.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support. As addressed more fully in the response directly above, we have made substantial adjustments to the certification criterion's scope and health IT developers accountability expectations. As a result of these changes, we have also addressed commenter concerns that there would be no limit on how much or what type of data can be missing. We have finalized in § 170.315(b)(11)(v)(A)(
                        <E T="03">2</E>
                        ) that only source attributes in § 170.315(b)(11)(iv)(B)(
                        <E T="03">6</E>
                        ); (b)(11)(iv)(B)(
                        <E T="03">7</E>
                        )(
                        <E T="03">iii</E>
                        ), (
                        <E T="03">iv</E>
                        ), and (
                        <E T="03">v</E>
                        ); (b)(11)(iv)(B)(
                        <E T="03">8</E>
                        )(
                        <E T="03">ii</E>
                        ) and (
                        <E T="03">iv</E>
                        ); and (b)(11)(iv)(B)(
                        <E T="03">9</E>
                        ) may be missing and in these circumstances a health IT developer must indicate when information is not available for review.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters expressed concern that the proposal to require Health IT Modules to display missing source attributes could result in unfair market dynamics, in which developers of certified health IT will make available full and complete source attribute information for their homegrown or native DSIs while being less inclined to collect and meaningfully display such information from 
                        <E T="03">other parties</E>
                         developing and offering Predictive DSIs. Several commenters noted that the proposal would not compel third-party creators to provide the information to the health IT developer, or to renegotiate existing contracts to compel the provision of source attributes.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for these concerns and suggestions. We did not propose and we have not finalized 
                        <PRTPAGE P="1270"/>
                        a policy that regulates 
                        <E T="03">other parties</E>
                         and this final rule does not compel 
                        <E T="03">other parties</E>
                         to provide source attribute information to developers of certified health IT. Rather, we believe there is sufficient market-driven motivation for 
                        <E T="03">other parties</E>
                         to provide source attribute information for Predictive DSIs they author or develop to health care providers who seek to use their Predictive DSI's in addition to any of the ones supplied by a developer of certified health IT as part of its Health IT Module. We believe health IT users are likely to develop the expectation that information is available through source attributes and trust and choose to use Predictive DSIs that have the information contained in source attributes compared to those that do not, which may also create competitive pressure in the market to provide source attribute information. For example, the market incentives consumers have when choosing between vehicles that have complete history reports regarding accident damages, manufacturer buybacks, registration records, odometer readings, and ownership transfers, and those vehicles that do not. We believe similar market incentives will result in more source attribute information being made available for user review than would be the case absent the requirement to indicate when source attributes were not available for review.
                    </P>
                    <P>
                        In response to the commenter concerned about unfair market dynamics, we note that we have finalized a requirement that Health IT Modules must be capable of displaying source attributes from 
                        <E T="03">other parties</E>
                         and for users to be able to modify attributes for those Predictive DSI. But that is where the finalized requirements stop. With the exception of Predictive DSIs authored by the health IT developer or those it expressly chooses to supply as part of its Health IT Module, we have not required health IT developers with Health IT Modules certified to § 170.315(b)(11) to receive, acquire, or otherwise produce source attributes related to 
                        <E T="03">other party</E>
                         DSIs. We encourage those 
                        <E T="03">other parties</E>
                         to work with their customers to ensure that source attribute information is full and complete, thereby addressing any potentially unfair market dynamics.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Another commenter suggested that developer of the other system, at most, could denote if a DSI it interfaces with is in fact a third-party model, thus informing the user of the need to seek out any desired information from the primary developer of the DSI in question.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As part of this final rule's focus on providing information only for Predictive DSIs supplied in Health IT Modules, we decline to require that Health IT Modules display or “denote” when another system includes a third-party model.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters stated that communicating that a model is third-party is sufficient and stated that while the proposed language of saying source attribute information is “not available for user review” is both unnecessarily pejorative to the third party and misleading to the end user.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized at § 170.315(b)(11)(v)(B)(
                        <E T="03">1</E>
                        ) that Health IT Modules must “Enable a limited set of identified users to record and change source attributes in paragraphs (b)(11)(iv)(A) and (B) of this section,” but have left flexibility to developers of certified health IT and their customers to choose if and how to indicate that information is missing, when they believe doing so is valuable, so that they may avoid pejorative and misleading language.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern with the phrase “
                        <E T="03">other parties”</E>
                         because it could encompass healthcare delivery organizations that self-develop Predictive DSI for “in-house” use to augment their purchased EHR system and requested an exemption from certain requirements, and that they not be penalized by ONC or their EHR vendor who could pass on “costs” to use their “in-house” tools.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for their concern. We believe this final rule's focus on providing information only for Predictive DSIs supplied by health IT developers in their Health IT Modules will reduce concerns around a need for specific exemptions or that developers of certified health IT might pass on costs, since those developers are only likely to incur costs for those Predictive DSI they supply. Predictive DSI that a healthcare delivery organization self-developed and used to augment their Health IT Module would likely not be considered supplied by health IT developers.
                    </P>
                    <P>
                        As noted previously in this final rule, we have maintained our description of “
                        <E T="03">other parties.</E>
                        ” For the purposes of the Program, compliance clarity, and distinguishing a health IT developer's own authored and supplied Predictive DSIs from everyone else, we use the phrase “
                        <E T="03">other party,</E>
                        ” which could include a health care provider who self-develops a Predictive DSI. That said, as we have conveyed this final rule's requirements, being described as an 
                        <E T="03">other party</E>
                         imposes no specific regulatory compliance requirement.
                    </P>
                    <HD SOURCE="HD3">x. Authoring and Revising Source Attributes</HD>
                    <P>
                        At proposed § 170.315(b)(11)(vi)(E), we proposed that Health IT Modules certified to § 170.315(b)(11) support the ability for a limited set of identified users to author (
                        <E T="03">i.e.,</E>
                         create) and revise source attributes and information provided for user review beyond the specific source attributes we enumerated (88 FR 23796-23797). This proposal applied to source attributes related to both evidence-based DSIs and Predictive DSIs that would be enabled by or interfaced with a certified Health IT Module, including any Predictive DSIs that could have been developed by users of the certified Health IT Module, and we described specific examples in the HTI-1 Proposed Rule. While we did not propose to require a developer of certified health IT to be directly involved in the authoring or revision of source attribute information provided for user review, we proposed that the certified Health IT Module would need to support the technical ability for a limited set of identified users to create new or revised attribute information alongside other source attribute information proposed as part of § 170.315(b)(11)(vi)(A) and (C).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A majority of commenters did not support the proposal that Health IT Modules certified to § 170.315(b)(11) support the ability for a limited set of identified users to author (
                        <E T="03">i.e.,</E>
                         create) and revise source attributes and information provided for user review beyond what was proposed. One commenter supported the concept of hospitals and providers creating their own Predictive DSI models and suggested that developers should only be expected to create functionality to allow users to enter their own source attributes and that developers should not have responsibility for gathering that information for users for input into the products. One commenter expressed concern that it is unclear whether the expectation is that developers must allow for customers to revise the source attributes that developers have themselves defined for DSIs they have developed, noting that allowing revisions would seem problematic as it could inappropriately alter the meaning and information being relayed to end-users. Commenters recommended that we clearly indicate that this requirement applies solely to additional/supplementary source attributes for DSIs developed by the developer of certified health IT themselves stating that DSIs that are not directly implemented or enabled by the developer should be out of scope for the 
                        <PRTPAGE P="1271"/>
                        criterion. Commenters were especially concerned that the proposal failed to define the intent for, or characteristics of, the limited set of identified users and would enable those users to create extra regulatory requirements for developers of certified Health IT Modules.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments and believe that coupled with the proposed scope for the certification criterion that some commenters may have misinterpreted the intent behind our proposal and how the technical capabilities for a Health IT Module would play out as part of implementation. We note that several source attributes, particularly those now finalized in § 170.315(b)(11)(iv)(B)(
                        <E T="03">6</E>
                        )-(
                        <E T="03">9</E>
                        ) pertain to activities that may occur within individual customer sites, so that processes to measure validity and fairness, as well as the results of those processes, are likely to differ across customer sites. We believe individual customers will have substantial value in revising these source attributes. We clarify that developers of certified health IT are not responsible for content recorded, changed, or accessed by these users and are not responsible for gathering information for or from users that wish to record or change source attribute information.
                    </P>
                    <P>We nevertheless understand commenters' concerns related to modification of source attributes related to Predictive DSIs that are developed by health IT developers. We clarify that developers of certified health IT are not responsible for the accuracy or use of source attribute information that is modified by their users. Rather, developers of certified health IT are required to have Health IT Modules that support the capability for their users to author or revise source attribute information. We emphasize that this capability is not dependent on the entity that developed the Predictive DSI or related source attributes and we decline to limit this capability to only those additional/supplementary source attributes for DSIs developed by a developer of certified health IT. We note that a Health IT Module is required to enable a “limited set of identified users,” to author and revise source attributes. We believe this stipulation ensures that a Health IT Module is capable of enabling some specified users, but not all users, to have the capability to author and revise source attributes and we believe this mitigates concerns around inappropriate alteration. This requirement will not provide these users with the ability to create additional regulatory requirements but simply to display information related to source attributes of their choosing. We note that several certification criteria include the phrase “limited set of identified users,” including the CDS criterion at § 170.315(a)(9), which developers of certified health IT have had more than a decade of experience supporting.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters did not agree with the proposal that Health IT Modules certified to § 170.315(b)(11) support the ability for a limited set of identified users to author (
                        <E T="03">i.e.,</E>
                         create) and revise source attributes and information provided for user review beyond what was proposed in § 170.315(b)(11)(vi)(A) and (C). These commenters noted that it could be burdensome on device manufactures, be at odds with FDA device requirements, adulterate the functionality of the device, and could possibly invalidate any testing and validity provided by the developers or require such robust testing for all permutations that quality and cost could be impacted. Commenters were concerned about the impact on FDA approved devices, observing that allowing third-party developers and users to alter source attribute information, including information related to the “intended use” of the device, may be considered an alteration to the device and impact FDA approval.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' concerns regarding FDA-approved medical devices and alterations to the devices intended use source attribute. We note that the source attribute related to intended use is a description of what the output of the Predictive DSI should be used for and not a bound indication of what a devices may be approved to do. While we do not expect users to change the intended use of a Predictive DSI, the requirement is that a Health IT Module enable a limited set of users to change and record source attribute information. We believe that developers of certified health IT and their customers are best positioned to jointly decide how broadly to provide the ability to change and record source attributes and under what circumstances. Customers could then decide what set of users should have the ability to record and change source attribute information in the capabilities adopted in final § 170.315(b)(11)(iv)(A) and (B). In many cases, we believe that FDA requirements and the information included as source attributes are closely aligned, limiting burden on developers. Where that is not the case, we believe the information provided as source attributes will have substantial values to users commensurate with implied burden. Though required, developers concerned about changes to their original source attribute information are free to include a capability to allow users to review the original source attributes even when the information has been changed by end users.
                    </P>
                    <P>
                        We have finalized our requirements related to revising source attribute information with modifications at § 170.315(b)(11)(v)(B)(
                        <E T="03">1</E>
                        ), which requires that a Health IT Module must enable a limited set of identified users to record and change source attributes in § 170.315(b)(11)(iv)(A) and (b)(11)(iv)(B). As previously discussed, § 170.315(b)(11)(v)(B) is a modified version of proposed § 170.315(b)(11)(iv) and § 170.315(b)(11)(vi)(E), combining the “author and revise” concepts of § 170.315(b)(11)(iv)(E) with the “review” concept in § 170.315(b)(11)(iv). In finalizing this language, we intend to clearly convey that individuals can record and change information within the source attributes listed at § 170.315(b)(11)(iv)(A) and (b)(11)(iv)(B).
                    </P>
                    <P>
                        We are also aware of substantial activity by the public, industry groups, and other advocacy organizations to further transparency related to Predictive DSIs. Along those lines, we have observed that variations exist with respect to each initiative's priorities and that there is not strong consensus among these groups related to the information included as source attributes or transparency information.
                        <SU>129</SU>
                        <FTREF/>
                         As technology related to Predictive DSIs continues to evolve and as industry consensus matures, we expect that new information may need to be made available through source attributes for new models. In recognition of the fact that this final rule now sets a consistent, industry-wide baseline set of source attributes on which these groups may wish to build, we have retained a requirement at § 170.315(b)(11)(v)(B)(
                        <E T="03">2</E>
                        ) around authoring source attributes in addition to those listed in § 170.315(b)(11)(iv)(B). This capability will help support health care providers who wish to stay at pace with industry consensus around transparency and include additional source attribute information using their certified health IT to do so.
                    </P>
                    <FTNT>
                        <P>
                            <SU>129</SU>
                             See, for instance, work by the coalition for health AI 
                            <E T="03">https://www.coalitionforhealthai.org/</E>
                             and the health AI partnership 
                            <E T="03">https://healthaipartnership.org/.</E>
                        </P>
                    </FTNT>
                    <P>
                        In § 170.315(b)(11)(v)(B)(
                        <E T="03">2</E>
                        ) we have finalized that for Predictive DSIs, the Health IT Module must enable a limited set of identified users to record, change, and access additional source attribute information not specified in paragraph (b)(11)(iv)(B). First, we have limited this 
                        <PRTPAGE P="1272"/>
                        capability to only Predictive DSI source attributes in § 170.315(b)(11)(iv)(B), whereas our proposal applied to both evidence-based and Predictive DSIs. This is intended to be responsive to commenters who worried that the scope of this capability was too burdensome to implement. Second, we have modified the capability from “author and revise source attributes beyond those listed” to the capability to “record, change, and access additional source attribute information not specified.” We believe this more clearly articulates the intent of the policy and addresses concerns regarding questions posed by interested parties on what “beyond,” meant within the context of their obligations. We clarify that developers of certified Health IT Modules are not responsible for the content recorded, changed, or accessed by these users.
                    </P>
                    <HD SOURCE="HD3">xi. Intervention Risk Management (IRM) Requirements for Predictive Decision Support Interventions</HD>
                    <P>
                        At 88 FR 23797-23808, we proposed to establish “intervention risk management” (IRM) requirements. We proposed at 88 FR 23797 to require that by December 31, 2024, a developer of certified health IT that attested “yes” as part of our other proposal would need to employ or engage in certain IRM practices for all Predictive DSIs, as we proposed at 88 FR 23785 to define in § 170.102, that the developer's certified Health IT Module enables or interfaces with. We also proposed that developers of certified health IT analyze potential risks and adverse impacts associated with a Predictive DSI for the following characteristics: validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy at § 170.315(b)(11)(vii)(A)(
                        <E T="03">1</E>
                        ) (88 FR 23799-23801). Similarly, we proposed that developers of certified health IT implement practices to mitigate risks associated with intervention Predictive DSIs at § 170.315(b)(11)(vii)(A)(
                        <E T="03">2</E>
                        ) (88 FR 23801-23802). And, related to governance, we proposed that developers of certified health IT would need to establish policies and implement controls for Predictive DSI governance, including how data are acquired, managed, and used in a Predictive DSI at § 170.315(b)(11)(vii)(A)(
                        <E T="03">3</E>
                        ) (88 FR 23802-23803).
                    </P>
                    <P>With respect to documentation, we proposed at § 170.315(b)(11)(vii)(B) that developers of certified health IT compile detailed documentation of IRM practices and upon request from ONC make available such detailed documentation for any Predictive DSI that their certified Health IT Module enables or interfaces with (88 FR 23803-23804). We also proposed at § 170.315(b)(11)(vii)(C) to require developers of certified health IT to submit summary information to their ONC-ACB regarding IRM practices listed via a publicly accessible hyperlink that would allow any person to directly access the information without any preconditions or additional steps (88 FR 23804). Consistent with Program implementation for similar documentation requirements (84 FR 7484), we proposed that for this proposed summary information, the required documentation would need to be submitted to ONC-ACBs for review prior to issuing a certification (88 FR 23805).</P>
                    <P>Finally, we proposed at § 170.315(b)(11)(vii)(D) to require that developers of certified health IT review annually and, as necessary, update both detailed documentation and summary information associated with the certification criterion (88 FR 23805). We also proposed to establish a deadline of December 31, 2024, for developers of certified health IT with Health IT Modules to which the proposed requirements in that section apply to engage in IRM practices and develop both detailed documentation and summary information (88 FR 23797). This proposed deadline corresponded with other proposals in the HTI-1 Proposed Rule, including our proposed to update the Base EHR definition (88 FR 23808).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters both supported and opposed our proposed IRM requirements at § 170.315(b)(11)(vii), with those in support noting the proposed risk management practices of risk analysis, risk mitigation, and governance are essential for ensuring the trustworthiness of Predictive DSIs. One commenter suggested that ONC strengthen its risk analysis requirements to include intended and reasonably expected DSI use(s), DSI evidence of safety, DSI efficacy, DSI level of automation, and conditions of DSI deployment, whereas another commenter recommended ONC limit its risk analysis requirements to predictive clinical DSIs. Commenters were especially supportive of our proposal to adopt NIST's AI Risk Management Framework (AI RMF) because they noted the characteristics in the proposal provide a robust framework to help with risk mitigation.
                        <SU>130</SU>
                        <FTREF/>
                         Some commenters recommended that we follow the Congressionally-created National Artificial Intelligence Advisory Committee (NAIAC) recommendation to use either the NIST AI RMF or similar processes and policies that align with NIST AI RMF. One commenter was supportive to use the NIST Characteristics for FAVES, but recommended revisions to the Fairness, Intelligibility, and Safety characteristics. One commenter who supported the proposal suggested that ONC should strengthen the proposed requirements to explicitly require that a health IT developer's risk mitigation practice include additional information on addressing bias, safeguarding privacy, security interests, and personal information, and create a full feedback loop.
                    </P>
                    <FTNT>
                        <P>
                            <SU>130</SU>
                             NIST AI Risk Management Framework, 
                            <E T="03">https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments and agree that risk management practices are essential for ensuring the trustworthiness of Predictive DSIs and that these practices would promote transparency and accountability within healthcare. As described further in this section we have finalized in § 170.315(b)(11)(vi) substantially similar versions of our proposals. The finalized certification criterion requires that IRM practices must be applied for each Predictive DSI supplied by the health IT developer as part of its Health IT Module, including risk analysis, risk mitigation, and governance. We have also finalized modified versions of what we proposed related to IRM summary information in § 170.523(f)(1)(xxi) as well as the annual review and updated documentation requirements in § 170.402(b)(4). We have 
                        <E T="03">not</E>
                         finalized our proposal that developers of certified health IT compile detailed documentation of IRM practices listed in § 170.315(b)(11)(vii)(A) and upon request from ONC make available such detailed documentation for any Predictive DSI that their certified Health IT Module enables or interfaces with.
                    </P>
                    <P>
                        We thank commenters for their support of our proposal's consistency with the NIST AI RMF and the National Association of Insurance Commissioners (NAIC) recommendation to use either the NIST AI RMF or similar processes and policies that align with the NIST AI RMF.
                        <SU>131</SU>
                        <FTREF/>
                         While we encourage the use of 
                        <PRTPAGE P="1273"/>
                        a framework to help facilitate IRM and adapted the NIST AI RMF concepts and emphasis areas, conformance with this certification criterion does not require the use of any particular framework, approach, or methodology for providing information about risk management practices. As noted in HTI-1 Proposed Rule (88 FR 23798), we have left this flexibility given a lack of healthcare sector-specific guidance and the nascency of several emerging efforts for risk management of predictive software.
                    </P>
                    <FTNT>
                        <P>
                            <SU>131</SU>
                             As noted in the HTI-1 Proposed Rule (88 FR 23810) (footnote 289), we are aware of and coordinated with multiple federal agencies and activities focused on AI, including the NAIC, that are also exploring policies to prevent and mitigate bias in AI/ML and the intersection with privacy, equity, and civil rights. For more information about the Congressionally-created NAIC and its recommendation for federal agencies, please see the NAIC Year 1 Report (May 2023), available at: 
                            <PRTPAGE/>
                            <E T="03">https://www.ai.gov/wp-content/uploads/2023/05/NAIAC-Report-Year1.pdf.</E>
                        </P>
                    </FTNT>
                    <P>We appreciate commenters' suggestions on additional characteristics and additional kinds of risks that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) should include as part of their IRM practices. However, we remained consistent with what we proposed and decline to add further characteristics. We believe that the eight areas we have finalized represent consensus focus areas, are based on the NIST AI RMF, and would be most relevant to Predictive DSIs. We will monitor implementation of this requirement and may consider modifications to these characteristics in future rulemaking.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters not in support of the IRM requirements proposed at § 170.315(b)(11)(vi), expressed significant concerns that they would require disclosing IP or proprietary information, could compromise patient privacy, and increase administrative burdens. Other commenters did not support the IRM requirements because they thought they were too broad, noting that requiring a developer of certified health IT to perform IRM practices over a third party's DSI tool is neither feasible or competitively rational and recommended that we limit the scope so that developers are accountable for IRM practices for its own DSI only. Other commenters that did not support the IRM proposals urged ONC to consider a risk-based DSI approach that would classify high, moderate, and low risk DSIs and would provide developers with appropriately scaled risk-based controls based on potential harm to individual patients and populations. One commenter expressed concern that some developers may engage in risky practices that result in harm or privacy violations and requested more clarity on how certification criteria would exclude developers from engaging in these practices. One commenter expressed concern that there is not enough time for developers to meet the December 31, 2024, deadline due to the time to develop and implement the requirements and requested additional time to address the eight characteristics of risk.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their concerns and suggestions. As we have noted throughout this rulemaking, we believe that such transparency is a prerequisite for high-quality Predictive DSIs to be trusted by clinicians, patients, health systems, software developers, and other interested parties. When we developed the proposed IRM requirements, we sought a balance between limited prescriptiveness and sufficient detail to enable robust and broadly applicable reporting of information on risk management practices to users and the public. Our proposed requirements focused on potential risks and adverse impacts (harm) in eight areas, that include privacy and fairness, that may be associated with each Predictive DSI that is authored by the health IT developer.
                    </P>
                    <P>
                        In consideration of the feedback we received, we believe that the finalized IRM requirements strike the best balance, especially given that we have not established requirements for specific measures. Rather, we have given maximum flexibility to developers of certified health IT to determine which information best fits their unique circumstances and Predictive DSI use cases. We encourage developers of certified health IT to examine industry resources, such as the NIST AI RMF or the Health Equity Across the AI Lifecycle (HEAAL) framework,
                        <SU>132</SU>
                        <FTREF/>
                         as part of these requirements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>132</SU>
                             Kim J., Hasan A., Kellogg K., et al. Development and preliminary testing of Health Equity Across the AI Lifecycle (HEAAL): A framework for healthcare delivery organizations to mitigate the risk of AI solutions worsening health inequities. medRxiv 2023.10.16.23297076; doi: 
                            <E T="03">https://doi.org/10.1101/2023.10.16.23297076.</E>
                        </P>
                    </FTNT>
                    <P>Further, as stated in the HTI-1 Proposed Rule (88 FR 23799), we believe that many such developers of certified health IT already employ or engage in IRM practices to comply with existing certification criteria (§ 170.315(g)(3) “safety-enhanced design” (SED) and § 170.315(g)(4) Quality management systems (QMS)). Thus, we continue to believe that the finalized requirement to provide information on these practices represents a low-level of burden for those developers. We believe that our IRM practice requirements are important for several reasons. First, all developers of certified health IT that seek certification to § 170.315(b)(11) and supply Predictive DSIs as part of their Health IT Module will become familiar with foundational IRM practices. Second, the public disclosure of the summary information of IRM practices employed or engaged by the developer of certified health IT, as described further below, will provide transparency to purchasers (potential users), users, and other interested parties, and contribute to appropriate information to help guide medical decisions. Lastly, our finalized requirements in § 170.315(b)(11)(vi)(A) will encourage development of healthcare-specific, consensus, and industry-based best practices for risk management.</P>
                    <P>
                        We appreciate the concerns expressed about IP and proprietary information, patient information privacy, and administrative burden. As noted, as part of this certification criterion's preamble we have made scope adjustments in response to public comment that we believe substantially address these concerns. The finalized requirements for risk analysis and risk mitigation are limited to only those Predictive DSIs supplied by the developer of health IT as part of its Health IT Module. We have also clarified our expectations for governance requirements. With the exception of 
                        <E T="03">other party</E>
                         Predictive DSI's supplied by developers of health IT as part of their Health IT Module, we have 
                        <E T="03">not</E>
                         finalized the proposals (88 FR 23803) that caused commenters' concerns regarding the developer of certified health IT performing “IRM practices over a third party's DSI.” Specifically, we have not finalized that developers review risk management information from 
                        <E T="03">other parties</E>
                         nor that developers include risk management information from 
                        <E T="03">other parties</E>
                         as part of the documentation requirement.
                    </P>
                    <P>
                        We appreciate the concern expressed about information privacy and harm. We expect that model developers will use data for training and testing consistent with applicable law, patients' expectations, and any patient consent or preference given. We believe the scope changes we have made as part of this finalized certification criterion along with the high degree of flexibility we provide to developers of certified health IT to establish appropriate risk management practices mitigate concerns related to compromising IP, proprietary information, and patient privacy. While we appreciate the concerns raised by some commenters, based on the final certification criterion's scope, we believe they are outweighed by the need to promote greater and more meaningful disclosure of information by developers of health IT certified. We disagree with the claims that our requirements for summary information about risk management practices would result in 
                        <PRTPAGE P="1274"/>
                        disclosing IP or proprietary information as we are entrusting developers of certified health IT to disclose information at a level of detail according to their own judgments. Furthermore, based on the scope of the final certification criterion, it is reasonable to assume that developers of certified health IT are experts on their own products and services and possess sophisticated technical and market knowledge related to the implementation and use of health IT in a variety of settings in which their products are used. Through their accumulated experience developing and providing health IT solutions to their customers, health IT developers should be familiar with the types of risks that most users encounter, and therefore must describe these in sufficient detail to provide potential customers, patients, or researchers, with the information they need to make informed applicability, scope, and use decisions.
                    </P>
                    <P>As for recommendations that we take a risk-based approach to IRM requirements, we appreciate the comment. However, the Program is not predicated on levels of risk and our requirements for certification to the DSI (formerly CDS) criterion has been and continues to be agnostic to specific use cases, intended uses, and risks. We reiterate that we are not establishing requirements for specific measures. Rather, we are giving maximum flexibility for developers of certified health IT to determine which information best fits their unique circumstances and Predictive DSI use cases.</P>
                    <P>
                        As noted in the HTI-1 Proposed Rule (88 FR 23802), developers of certified health IT have the flexibility to choose an approach to meeting this requirement that addresses their own unique circumstances for their Predictive DSIs. However, we encourage developers to implement policies and controls to evaluate whether risk analysis and risk mitigation practices are being carried out as specified; to consider how policies and controls are monitored and updated; and to plan a schedule for updating those policies and controls. Policies and controls should include details on roles, responsibilities, staff expertise, authority, reporting lines, and continuity. We further encourage developers to have accountability and escalation policies and controls related to how management oversees the development, deployment, and management of Predictive DSIs.
                        <SU>133</SU>
                        <FTREF/>
                         These policies and controls should describe the developer of certified health IT's decision-making parameters or programs and include how management is held accountable for the impact of Predictive DSIs. We encourage developers to identify staff that are responsible for Predictive DSIs and related models and to develop policies to hold those staff accountable to the developer's established policies and procedures.
                        <SU>134</SU>
                        <FTREF/>
                         We believe that developers should plan escalation processes that permit significant issues with Predictive DSI development, integration, or use to reach appropriate levels of management and describe standards for timely resolution of issues with Predictive DSIs and related models.
                        <SU>135</SU>
                        <FTREF/>
                         If the developer uses a third party to assess risk, the developer should describe processes for determining whether assessments performed by a third party meet the standards and controls set forth in the developer's governance framework.
                    </P>
                    <FTNT>
                        <P>
                            <SU>133</SU>
                             Off. Comptroller Currency, Comptroller's Handbook: Model Risk Management (Aug. 2021), 
                            <E T="03">https://www.occ.gov/publications-and-resources/publications/comptrollers-handbook/files/model-risk-management/index-model-risk-management.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>134</SU>
                             Id.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>135</SU>
                             Id.
                        </P>
                    </FTNT>
                    <P>We appreciate the commenter's concerns about meeting the December 31, 2024, deadline, and the desire for an extension. We note that in prioritizing this certification criterion, we have finalized longer timelines for the adoption of other standards and certification criteria with, for example, a compliance date of January 1, 2026. We believe the extended dates for conformance with these other standards and certification criteria will make it more feasible for the industry to meet the December 31, 2024, deadline for the finalized requirements in § 170.315(b)(11). We discuss timing requirements in more detail below in the section on modifications to the “Base EHR.”</P>
                    <P>After consideration of public comments received, we have finalized with modifications our proposed requirements for IRM practices. Specifically, we have finalized in § 170.315(b)(11)(vi) that IRM practices must be applied for each Predictive DSI supplied by the health IT developer as part of its Health IT Module. This finalized requirement applies to Predictive DSIs “supplied by the health IT developer as part of its Health IT Module,” which establishes an equivalent scoping between what we proposed under the attestation statement in proposed § 170.315(b)(11)(v) and what we have finalized in § 170.315(b)(11)(vi). As proposed, only those developers that attested “yes,” would have had to employ or engage in IRM practices and as finalized, only developers that supply Predictive DSIs are required to apply IRM practices. We have finalized § 170.315(b)(11)(vi)(A) requiring that Predictive DSIs must be subject to analysis of potential risks and adverse impacts associated with the following characteristics: validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy, which is substantially similar to what we proposed. We have finalized § 170.315(b)(11)(vi)(B) requiring that Predictive DSIs must be subject to practices to mitigate risks, identified in accordance with (b)(4)(ii)(A) of this section, which is substantially similar to what we proposed. We have finalized § 170.315(b)(11)(vi)(C) requiring that Predictive DSIs must be subject to policies and implemented controls for governance, including how data are acquired, managed, and used, for all Predictive DSIs supplied by the health IT developer as part of its Health IT Module, which is substantially similar to what we proposed.</P>
                    <P>We have also finalized requirements in § 170.523(f)(1)(xxi) as part of the Principles of Proper Conduct for ONC-ACB's that an ONC-ACB shall, where applicable, ensure that summary information of the IRM practices listed in paragraph § 170.315(b)(11)(vi) is submitted by the health IT developer via publicly accessible hyperlink that allows any person to access the summary information directly without any preconditions or additional steps. We have finalized this requirement as a combination of what we proposed in § 170.315(b)(11)(vii)(C) and what we proposed as a modification the Principles of Proper Conduct for ONC-ACB in § 170.523(f)(1)(xxi)</P>
                    <P>
                        Finally, as stated previously, we have finalized a new Assurances Maintenance of Certification requirement in § 170.402(b)(4) that requires developers of Health IT Modules certified to § 170.315(b)(11), starting January 1, 2025, and on an ongoing basis thereafter, review and update, as necessary, source attribute information in § 170.315(b)(11)(iv)(A) and (B), risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi). This requirement is substantially similar to what we had included in our proposal (such as § 170.315(b)(11)(vii)(D)). We provide additional details on § 170.402(b)(4) in previous comment responses in section III.C.5.v. “Predictive Decision Support Interventions, Attestation for Predictive 
                        <PRTPAGE P="1275"/>
                        Decision Support Interventions,” of this final rule.
                    </P>
                    <P>We reiterate that ONC has not adopted specific risk analysis metrics or risk mitigation practices beyond describing eight characteristics in § 170.315(b)(11)(vi)(A) and we note that developers of certified health IT may vary their IRM practices based on their understanding of the risk of each Predictive DSI.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concerns that the nature of the proposed documentation required in the IRM disclosure requirements that developers would have to meet would require a third-party developer to share proprietary technical and governance information and requested clarification on the level of detail required in documentation that IRM practices are employed. One commenter requested clarification on how developers of health IT would meet the proposed documentation requirements in § 170.315(b)(11)(vii)(B) when they would need to obtain the documentation from third-party developers. Several commenters did not support our IRM proposals due to the burdens it would place on health IT developers and recommended that we limit the IRM proposals to health IT developers who develop their own Predictive DSI models.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their concerns. After consideration of these comments, we have not finalized the requirements described in the HTI-1 Proposed Rule preamble for developers of certified health IT to receive or have access to risk management information for Predictive DSIs developed by 
                        <E T="03">other parties</E>
                         (and that are not supplied by the developer as part of its Health IT Module). After consideration of these comments, we have not finalized the requirements described in the HTI-1 Proposed Rule (88 FR 23803) preamble for developers of certified health IT to receive or have access to risk management information for Predictive DSIs developed by 
                        <E T="03">other parties</E>
                         (and that are not supplied by the developer as part of its Health IT Module). This means there are no expectations that developers review risk management information from 
                        <E T="03">other parties</E>
                         with whom they have no relationship and with whom they have not expressly chosen to supply a Predictive DSI as part of their Health IT Module. This also excludes all 
                        <E T="03">other party</E>
                         Predictive DSIs that their customers choose to implement as well as any Predictive DSIs that their customers author.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters believed that developers, and not health care providers, should ultimately be responsible for the tools they create and bear responsibility for harmful outcomes resulting from the tools being used as intended. Whereas other commenters suggested that the responsibility for risk assessment and mitigation should be shared with DSI providers and authors of the toolset, rather than requiring the health IT developers to accept all responsibilities.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the commenters' concerns. We agree that multiple parties share responsibility for risk assessment and mitigation and the safe application of Predictive DSI, and note that this rule does not alter any party's responsibility for exercising sound professional judgment in making clinical decisions and complying with applicable laws.
                        <SU>136</SU>
                        <FTREF/>
                         Developers and health care providers should implement practices in full awareness that this final rule will not change their responsibility under other applicable law. We have finalized requirements aligned with our authorities for developers of certified health IT, and we anticipate these requirements for IRM practices will help spur much-needed conversations across providers and their health IT partners on how best to analyze, mitigate, and govern risks associated with Predictive DSIs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>136</SU>
                             
                            <E T="03">See e.g.,</E>
                             U.S. Dept of Health &amp; Human Servs., Office for Civil Rights, Notice of Proposed Rulemaking, Nondiscrimination in Health Programs and Activities, 87 FR 47824, 47880 (Aug. 4, 2022), 
                            <E T="03">https://www.federalregister.gov/documents/2022/08/04/2022-16217/nondiscrimination-in-health-programs-and-activities</E>
                             (prohibiting discrimination on the basis of race, color, national origin (including limited English proficiency), sex (including sexual orientation and gender identity), age, or disability in certain health programs or activities 
                            <E T="03">through the use of clinical algorithms in their decision-making</E>
                            ); Title VI of the Civil Rights Act of 1964, 42 U.S.C. 2000d 
                            <E T="03">et seq.</E>
                             (prohibiting discrimination on the basis of race, color, or national origin (including limited English proficiency) in federally funded programs or activities); Title IX of the Education Amendments of 1972, 20 U.S.C. 1681 
                            <E T="03">et seq.</E>
                             (prohibiting sex discrimination in federally funded education programs or activities); the Age Discrimination Act of 1975, 42 U.S.C. 6101 
                            <E T="03">et seq.</E>
                             (prohibiting age discrimination in federally funded programs or activities); Section 504 of the Rehabilitation Act of 1973, 29 U.S.C. 794 (prohibiting disability discrimination in federally funded or federally conducted programs or activities); and the Americans with Disabilities Act, 42 U.S.C. 12101 
                            <E T="03">et seq.</E>
                             (prohibiting disability discrimination by employers, state and local government entities, and businesses that are open to the public, among others); The Health Insurance Portability and Accountability Act (HIPAA) Public Law 104-191,110 Stat. 1936 (August 21, 1996), codified at 42 U.S.C. 1320d-1320d8; HIPAA Privacy Rule, 45 CFR part 160 and subparts A and E of part 164; and The HIPAA Security Rule, 45 CFR part 160 and subparts A and C of part 164.
                        </P>
                    </FTNT>
                    <P>As noted in the HTI-1 Proposed Rule, we are aware that, in addition to developers of certified health IT, users, such as healthcare organizations and clinicians, have responsibilities related to Predictive DSIs, including intervention or model risk management during implementation and use, as well as model validation (88 FR 23805). For example, we believe it is important that users maintain strong governance and controls to help manage model risk and how they will use outputs from interventions in decision-making, including monitoring any potential impacts of model use. Users of a Predictive DSI are also best able to report on how the Predictive DSI performs in real world and local settings, which can differ from their performance during testing.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern that the proposal was too broad and recommended that ONC exclude from its transparency and risk management requirements any DSI tools that are created by a health care provider organization for its own use, with no intent to commercialize the tool(s). One commenter expressed concern that ONC did not account for the difference between “AI Developers” and “AI Deployers” noting that each has unique and distinct roles, and risk analysis requirements should account for these separate roles.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback. As we have noted as part of the certification criterion's discussion throughout this final rule, we have adjusted the scope of the certification criterion and clarified health IT developer responsibilities compared to health care providers and 
                        <E T="03">other parties.</E>
                         We clarify, based on the scope and policy for the final certification criterion, that “DSI tools created by a health care provider” for its own use are 
                        <E T="03">not</E>
                         in scope for Program requirements. More to the point, such health care providers will benefit from this final certification criterion's requirements because updated certified health IT will include more supportive capabilities for DSI transparency that they will be able to use for their own purposes. We appreciate the comment for differentiating between “AI Developers” and “AI Deployers,” however, we decline to establish different IRM practice requirements for different roles that may, or may not, exist across organizational boundaries. Our requirements pertain specifically to developers of certified Health IT Modules that supply Predictive DSIs as part of their Health IT Module.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concern about the potential liability of health IT developers and health care providers. One commenter expressed concern that some developers 
                        <PRTPAGE P="1276"/>
                        may attempt to shift liability for poor performing tools and recommended that the developer of the tool should bear the responsibility of ensuring optimal performance of the tool they developed and should bear the brunt of the liability when errors occur. One commenter recommended that we strengthen the requirements around IRM practices by requiring developers of certified health IT with Health IT Modules that enable or interface with Predictive DSIs to carry liability insurance that covers contingent bodily injury due to technology errors and omissions.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the commenter's concern for liability and accountability. We believe that our requirements for transparency in both performance, as indicated by the information required as part of source attributes, and in IRM practices will help users determine if tools are poor performing and make subsequent decisions on whether and how to use such tools. In general, these comments are outside of the scope of this rulemaking, and we decline to require liability insurance as part of our requirements and believe that issues of liability are outside the scope of this rulemaking. Those concerned or curious about it should reference federal, state, or tribal laws and regulations—or reliable sources information.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern that there is no requirement for real world testing in an uncontrolled environment and urged ONC require these activities are tested in real world scenarios before they are adopted to ensure DSIs are successful.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for their suggestion to require real world testing of Predictive DSIs. We note that among the source attributes listed in § 170.315(b)(11)(iv) there are two that would enable users to know if a Predictive DSI was tested for fairness at § 170.315(b)(11)(iv)(B)(
                        <E T="03">8</E>
                        )(
                        <E T="03">iii</E>
                        ) and (iv) and validity in local data at § 170.315(b)(11)(B)(iv)(
                        <E T="03">8</E>
                        )(
                        <E T="03">i</E>
                        ) and (
                        <E T="03">ii</E>
                        ). These source attributes are intended to support such real world testing; however, we are not requiring that such testing be done, so as noted within the certification criterion these source attributes may be missing. We also note that Health IT Modules certified to § 170.315(b)(11) must participate in real world testing as a Condition and Maintenance of Certification requirement as stipulated in § 170.405.
                    </P>
                    <HD SOURCE="HD3">Risk Analysis</HD>
                    <P>In the HTI-1 Proposed Rule (88 FR 23798-23799), we proposed to require developers of certified health IT to analyze potential risks and adverse impacts associated with a Predictive DSI that their certified Health IT Modules enable or interface with. NIST's AI RMF describes seven characteristics of trustworthy AI, and we proposed to adapt these concepts and require that developers of health IT with certified Health IT Modules that enable or interface with Predictive DSIs employ or engage in risk management practices related to the following characteristics: (1) validity; (2) reliability; (3) robustness; (4) fairness; (5) intelligibility; (6) safety; (7) security; and (8) privacy. We did not propose or describe risk tolerance associated with the eight characteristics, as we believe these should be decisions made by those involved with the design, development, deployment, and use of the technology. We proposed that developers of certified health IT must analyze the potential risks and adverse impacts, associated with a Predictive DSI that their certified Health IT Modules enable or interface with, related to lack or failure in the eight characteristics.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters were concerned that ONC did not establish or define regulatory baselines, measures, or thresholds for what constitutes FAVES for Predictive DSIs and noted that providers are not trained to independently assess whether a Predictive DSI was FAVES, nor is there a commonly accepted standard for review. Several commenters expressed concern that the IRM proposals could be duplicative of other federal agencies and could create conflicting regulatory schemes and urged ONC to consult and collaborate with federal partners and build on existing federal efforts to ensure bias, discrimination, and other health equity concerns were addressed through a unified AI government framework. One commenter recommended that the proposed “Safety” characteristic should explicitly exclude FDA-authorized AI and machine learning medical devices because they believe that a risk assessment for these tools is best made by the FDA due to their expertise in medical and clinical safety and being uniquely positioned to draw conclusions and develop guidelines for the safe and appropriate use of AI and machine learning tools.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Given the broad uses of Predictive DSIs, ONC did not seek to establish specific baselines, measures, or thresholds for what constitutes FAVES in the HTI-1 Proposed Rule. These measures are likely to vary based on specific technologies and uses of Predictive DSI. In many cases, the safety and effectiveness of a software function, including clinical decision support or other kinds of decision support interventions, is within the purview of FDA regulatory oversight, when such functionality meets the definition of a “device” under the FD&amp;C Act. As previously noted, ONC and FDA support a harmonized and complementary approach to predictive technology in accordance with our existing intersecting regulatory oversight. We sought to ensure there would be limited, if any, contradictory requirements. We note that we have afforded substantial flexibility to developers in practicing IRM. For tools that have been authorized by the FDA, we believe it would be appropriate for developers to provide information on FDA authorization as part of the “Safety” characteristic. Furthermore, given the intersecting interest across the Department to address the use of AI in health, we consulted extensively with our HHS partners at AHRQ, FDA, and OCR as well as our federal partners at the FTC and VA in developing the HTI-1 Proposed Rule to advance our shared goals of promoting greater trust in Predictive DSIs in healthcare that are fair, appropriate, valid, effective, and safe to deliver patient care, enable an effective marketplace, and greater competition.
                        <SU>137</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>137</SU>
                             See generally HHS Press Release (April 2023), 
                            <E T="03">https://www.hhs.gov/about/news/2023/04/11/hhs-propose-new-rule-to-further-implement-the-21st-century-cures-act.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        After consideration of these comments, we have finalized requirements at § 170.315(b)(11)(vi)(A) that for each Predictive DSI supplied by the health IT developer as part of its Health IT Module, the Predictive DSI must be subject to analysis of potential risks and adverse impacts associated with Predictive DSI the following characteristics: validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy. We note that we have narrowed the scope of Predictive DSIs for which a developer is expected to analyze risks and adverse impacts to only those Predictive DSIs that are supplied by the health IT developer. As stated previously, this is in response to public comments concerned with the overall scope of our IRM practice requirements and the related burdens, difficulty, and concerns around potential proprietary information related with getting such information from 
                        <E T="03">other parties.</E>
                    </P>
                    <HD SOURCE="HD3">Risk Mitigation</HD>
                    <P>
                        In the HTI-1 Proposed Rule, we proposed to require implementation of practices to mitigate risks associated with Predictive DSIs (88 FR 23801). In 
                        <PRTPAGE P="1277"/>
                        the HTI-1 Proposed Rule, we proposed § 170.315(b)(11)(vii)(A)(
                        <E T="03">2</E>
                        ) to require implementation of practices to mitigate risks associated with Predictive DSIs (88 FR 23801). We noted that risk mitigation practices should seek to address adverse impacts or minimize anticipated negative impacts of Predictive DSIs on patients and populations. We stated model risk mitigation should include disciplined and knowledgeable development and implementation practices that are consistent with the real-world context of the model's use, intended specific application of the model, and goals of the model user.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern that some developers may engage in risky practices that result in harm or privacy violations and requested more clarity on how certification criteria would exclude developers from engaging in these practices. One commenter encouraged ONC to clearly define the types of risks or harms that would disqualify a developer from Program certification. One commenter expressed concern that our proposal lacked requirements for DSI systems on managing complaints, post market surveillance, and error or misuse detection guidance, as well as reporting requirements related to these issues.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their concerns. We note that developers should implement practices in full awareness that this final rule will not change their responsibility under other applicable laws,
                        <SU>138</SU>
                        <FTREF/>
                         including those that provide legal protections to minimize risk practices and prohibit discrimination. We expect that model developers will use data for training and testing consistent with applicable law, patients' expectations, and any patient consent or preference given. We decline to further specify practices that would disqualify a developer from the Program, beyond the eight characteristics that must be addressed. As it relates to managing complaints and reporting requirements, we note that ONC has long maintained a “health IT inquiry and feedback portal,” available where users and the public can file complaints and ask questions about products certified under the Program.
                        <SU>139</SU>
                        <FTREF/>
                         We also reiterate that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) will be required to engage in real world testing per requirements at § 170.405.
                    </P>
                    <FTNT>
                        <P>
                            <SU>138</SU>
                             See HIPAA Privacy and Security Rules, 45 CFR part 160 and subparts A and E of part 164; 15 U.S.C. 45(a) (Section 5 of the FTC Act) and Health Breach Notification Rule in 16 CFR part 318; U.S. Dept of Health &amp; Human Servs., Office for Civil Rights, Notice of Proposed Rulemaking, Nondiscrimination in Health Programs and Activities, 87 FR 47824, 47880 (Aug. 4, 2022), 
                            <E T="03">https://www.federalregister.gov/documents/2022/08/04/2022-16217/nondiscrimination-in-health-programs-and-activities</E>
                             (prohibiting discrimination on the basis of race, color, national origin (including limited English proficiency), sex (including sexual orientation and gender identity), age, or disability in certain health programs or activities 
                            <E T="03">through the use of clinical algorithms in their decision-making</E>
                            ); Title VI of the Civil Rights Act of 1964, 42 U.S.C. 2000d 
                            <E T="03">et seq.</E>
                             (prohibiting discrimination on the basis of race, color, or national origin (including limited English proficiency) in federally funded programs or activities); Title IX of the Education Amendments of 1972, 20 U.S.C. 1681 
                            <E T="03">et seq.</E>
                             (prohibiting sex discrimination in federally funded education programs or activities); the Age Discrimination Act of 1975, 42 U.S.C. 6101 
                            <E T="03">et seq.</E>
                             (prohibiting age discrimination in federally funded programs or activities); Section 504 of the Rehabilitation Act of 1973, 29 U.S.C. 794 (prohibiting disability discrimination in federally funded or federally conducted programs or activities); and the Americans with Disabilities Act, 42 U.S.C. 12101 
                            <E T="03">et seq.</E>
                             (prohibiting disability discrimination by employers, state and local government entities, and businesses that are open to the public, among others).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>139</SU>
                             
                            <E T="03">https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters supported our proposal for risk mitigation requirements. Several commenters recommended that ONC adopt a tiered or risk-based approach to IRM practices and adopt requirements that would only apply to applications that present a meaningful risk to patients, allowing ONC to focus on high risk DSIs. These commenters generally supported the assessment of risk in predictive models but stated that requiring all models to adhere to the same set of compliance and regulatory rigor seems both unnecessary and overly burdensome. Some of these commenters also thought a risk-based approach was appropriate for determining whether and which disclosure requirements were necessary to prevent stifling innovation and prevent overly restrictive reviews.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments supporting our proposal for risk mitigation. We decline to accept the recommendation to take a risk-based DSI approach as suggested. We reiterate that the Program is not predicated on levels of risk and the DSI criterion will continue to be agnostic to specific use cases, intended uses, and risks. As stated in the HTI-1 Proposed Rule (88 FR 23799), we will require the developers of certified health IT engage in and document risk management practices related to eight characteristics: (1) validity; (2) reliability; (3) robustness; (4) fairness; (5) intelligibility; (6) safety; (7) security; and (8) privacy. However, we have provided substantial flexibility in the risk management practices developers engage in within those characteristics and the associated documentation. Developers may therefore choose to apply different levels of rigor to the risk analysis, risk mitigation, and governance of different Predictive DSIs. Similarly, developers of certified health IT may choose to apply different levels of detail describing their approaches to risk management practices as part of the summary information that must be summited per requirements in § 170.523(f)(1)(xxi).
                    </P>
                    <P>
                        This approach also aligns with HIPAA Security Rule requirements for covered entities and business associates. HIPAA covered entities, such as health care providers and health plans, are generally among the customers of developers of certified health IT. In many cases, developers of certified health IT serve as HIPAA business associates to their covered entity customers, such as health care providers or health plans,
                        <SU>140</SU>
                        <FTREF/>
                         and thus must comply with the HIPAA Security Rule. The HIPAA Security Rule requires covered entities and business associates to identify and assess risks and vulnerabilities to the confidentiality, integrity, and availability of electronic PHI (“ePHI”) when conducting the risk analysis and risk management required by the Security Rule, including any risks of third-party access to a covered entity's or business associate's information systems that contain electronic protected health information.
                        <SU>141</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>140</SU>
                             See definitions of “business associate” and “covered entity” at 45 CFR 160.103.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>141</SU>
                             See the definition of “electronic protected health information” at 45 CFR 160.103.
                        </P>
                    </FTNT>
                    <P>
                        As noted in the HTI-1 Proposed Rule, similar to when a HIPAA covered entity or business associate engages with a cloud service provider,
                        <SU>142</SU>
                        <FTREF/>
                         a developer of certified health IT, supplying an 
                        <E T="03">other party</E>
                        -developed Predictive DSI as part of its Health IT Module,
                        <SU>143</SU>
                        <FTREF/>
                         should understand the ways in which the technology or solution offered by the 
                        <E T="03">other party</E>
                         would seek to connect to or integrate with the certified health IT developer's product(s), so that the covered entity or business associate can appropriately conduct its own risk analysis and establish risk management 
                        <PRTPAGE P="1278"/>
                        policies, as well as enter into appropriate Business Associate 
                        <SU>144</SU>
                        <FTREF/>
                         Agreements (BAAs).
                        <SU>145</SU>
                        <FTREF/>
                         For example, a health IT developer providing certified health IT as a business associate may consider including in its risk analysis any risks associated with a decision by a covered entity to connect or integrate an 
                        <E T="03">other party's</E>
                         Predictive DSI with the developer's certified health IT products.
                        <SU>146</SU>
                        <FTREF/>
                         Under the HIPAA Security Rule, business associates have an independent obligation to identify and manage risks, regardless of whether or not a BAA exists.
                        <SU>147</SU>
                        <FTREF/>
                         If a business associate relationship exists and a BAA does not exist, the absence of a BAA does not relieve the business associate from HIPAA Security Rule obligations.
                    </P>
                    <FTNT>
                        <P>
                            <SU>142</SU>
                             U.S. Department of Health and Human Services, Office for Civil Rights (OCR), Guidance on HIPAA &amp; Cloud Computing: 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>143</SU>
                             As noted in HTI-1 Proposed Rule at 88 FR 23796, we note that these “other parties” may or may not have a contractual relationship with the developer of certified health IT.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>144</SU>
                             See definition of “business associate” at 45 CFR 160.103. Business associates include a subcontractor that creates, receives, maintains, or transmits protected health information on behalf of the business associate.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>145</SU>
                             See 45 CFR 164.308(b) for information about the Security Rule's requirements for BAAs. 45 CFR 164.502(e) permits a covered entity to disclose PHI to a business associate and to allow a business associate to create, receive, maintain, or transmit PHI on its behalf, if the covered entity obtains satisfactory assurance that the business associate will appropriately safeguard the information. Additional guidance on BAAs, often referred to as business associate contracts, is available at 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>146</SU>
                             The risk is based on the connection permitted to the certified health IT product by the health IT developer and not whether the developer has a direct or contractual relationship to the other party.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>147</SU>
                             Business associates are required to comply with the requirements of the HIPAA Security Rule. 45 CFR 164.302. See OCR's Direct Liability of Business Associates, 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/factsheet/index.html;</E>
                             OCR's Security Rule Guidance material, available at: 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html?language=es.</E>
                        </P>
                    </FTNT>
                    <P>
                        After consideration of these comments, we have finalized at § 170.315(b)(11)(vi)(B) that for each Predictive DSI supplied by the health IT developer as part of its Health IT Module, the Predictive DSI must be subject to practices to mitigate risks, identified in accordance with § 170.315(b)(11)(vi)(A). We note that we have narrowed the scope of Predictive DSIs for which a developer is expected to mitigate risks to only those Predictive DSIs that are supplied by the health IT developer as part of its Health IT Module. As stated previously, this is in response to public comments concerned with the overall scope of our proposed IRM practices requirements and the related burdens, difficulty, and potential proprietary information concerns related with getting such information from 
                        <E T="03">other parties.</E>
                    </P>
                    <HD SOURCE="HD3">Governance</HD>
                    <P>
                        In the HTI-1 Proposed Rule, we proposed § 170.315(b)(11)(vii)(A)(
                        <E T="03">3</E>
                        ) to require that developers of certified health IT establish policies and implement controls for Predictive DSIs (88 FR 23802). We proposed that a developer of a certified Health IT Module that enables or interfaces with a Predictive DSI must establish policies and implement controls for how data are acquired, managed, and used for said Predictive DSI.
                        <SU>148</SU>
                        <FTREF/>
                         Governance should encompass models, software and data developed or provided by 
                        <E T="03">other parties</E>
                         as well as internally developed interventions.
                        <SU>149</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>148</SU>
                             See, 
                            <E T="03">e.g.,</E>
                             The Organisation for Economic Co-operation and Development (OECD), 
                            <E T="03">Recommendation of the Council on Health Data Governance, https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0433;</E>
                             General Accountability Office (GAO), AI: 
                            <E T="03">An Accountability Framework for Federal Agencies and Other Entities</E>
                             (June 2021), 
                            <E T="03">https://www.gao.gov/assets/gao-21-519sp.pdf;</E>
                             See generally GAO, 
                            <E T="03">Artificial Intelligence in Health Care: Benefits and Challenges of Technologies to Augment Patient Care,</E>
                             (Nov. 2020), 
                            <E T="03">https://www.gao.gov/products/gao-21-7sp.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>149</SU>
                             See NIST AI RMF 1.0, 
                            <E T="03">https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        At 88 FR 23802-23803, we provided a discussion of the flexibility developers of certified health IT would have to choose an approach to meeting this proposed requirement that addresses their own unique circumstances for their Predictive DSIs. This included setting and enforcing priorities for managing and using data as a strategic asset, which is a concept that identifies key activities of data governance as data identification, data management policy, data issues management, data assessment, data oversight, and data communications.
                        <SU>150</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>150</SU>
                             See for example Federal Data Strategy, Data Governance Playbook, 
                            <E T="03">https://resources.data.gov/assets/documents/fds-data-governance-playbook.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters supported our requirement to include “governance” as part of the IRM practices. However, many commenters also expressed concern regarding our expectation that developers of certified health IT review governance information from 
                        <E T="03">other parties</E>
                         or that 
                        <E T="03">other parties</E>
                         provide the developer of certified health IT with relevant IRM information so that such information may be available for both detailed and summary documentation.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' concerns. In response to public comments, we have not finalized the requirements described in the HTI-1 Proposed Rule for developers of certified health IT to receive or have access to specific risk management information from 
                        <E T="03">other parties</E>
                         except when the health IT developer supplies an 
                        <E T="03">other party</E>
                         Predictive DSI as part of its Health IT Module. We have finalized as part of Governance requirements in § 170.315(b)(11)(vi)(C), that for each Predictive DSI supplied by the developer as part of its Health IT Module, the Predictive DSI must be subject to policies and implemented controls for governance, including how data are acquired, managed, and used. As a result, we clarify that the expectation described in the HTI-1 Proposed Rule that developers receive or have access to risk management information for Predictive DSIs developed by 
                        <E T="03">other parties</E>
                         is generally inapplicable, unless the developer of health IT is the one supplying the 
                        <E T="03">other party'</E>
                        s Predictive DSI as part of its Health IT Module.
                    </P>
                    <P>
                        The NIST AI RMF Govern Section 6 discusses a need for policies and procedures to be in place to address AI risks and benefits arising from third-party software and data.
                        <SU>151</SU>
                        <FTREF/>
                         We note that while not required to follow the NIST AI RMF, developers of certified health IT may wish to review Govern Section 6 as this section provides a number of suggested actions and documentation questions that we believe would be informative towards meeting governance requirements.
                        <SU>152</SU>
                        <FTREF/>
                         Similarly, The Office of the Comptroller of Currency similarly described several best practices related to risk management of models developed by third parties, including seventeen specific items included on its internal control questionnaire.
                        <SU>153</SU>
                        <FTREF/>
                         Many of these practices could apply to the development of governance processes pertaining to risk management of models authored by 
                        <E T="03">other parties</E>
                         including, for example, “When relying on third-party models, does management obtain ongoing performance monitoring and outcomes analysis of the model conducted by third parties”.
                        <SU>154</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>151</SU>
                             NIST AI RMF. Govern, Section 6. Available at: 
                            <E T="03">https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook/Govern.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>152</SU>
                             Ibid. Transparency and Documentation.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>153</SU>
                             See Bd. Governors Fed. Rsrv. Sys., Off. of Comptroller of the Currency, Supervisory Guidance on Model Risk Management, SR Letter 11-7, (April 2011), 
                            <E T="03">https://www.federalreserve.gov/supervisionreg/srletters/sr1107.htm;</E>
                             Off. Comptroller Currency, Comptroller's Handbook: Model Risk Management (Aug. 2021), 
                            <E T="03">https://www.occ.gov/publications-and-resources/publications/comptrollers-handbook/files/model-risk-management/index-model-risk-management.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>154</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <PRTPAGE P="1279"/>
                    <HD SOURCE="HD3">Compile Detailed IRM Practice Documentation</HD>
                    <P>In the HTI-1 Proposed Rule, we proposed that a health IT developer that attests “yes” as part of proposed § 170.315(b)(11)(v)(A) would need to compile detailed documentation regarding IRM practices and upon request from ONC make available such detailed documentation to ONC for any Predictive DSI, as defined in § 170.102, that the certified Health IT Module enables or interfaces with (88 FR 23803). We noted our belief that a developer of certified health IT subject to this proposed requirement should be able to provide detailed documentation of their IRM practices, if ONC requests such information, without much effort because this information should be a byproduct of employing or engaging in IRM practices.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters were not supportive of the proposed requirements for detailed documentation of IRM practices and expressed concern that including the term “interfaces with” as it relates to the proposed IRM practices results in a policy that is too broad. Specifically, commenters noted that obtaining detailed documentation related to a third party's DSI tool is neither feasible nor competitively rational and recommended that we limit the scope so that developers are accountable for IRM practices for its own DSI only. One commenter requested clarification on how developers of health IT would meet the proposed documentation requirements when they would need to obtain documentation from third-party developers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As discussed throughout this section, we have finalized a more specific and limited scope for Predictive DSIs that are supplied by the health IT developer as part of its Health IT Module. After consideration of these comments, we have not finalized the proposals requiring developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) to compile detailed documentation regarding the IRM practices listed in paragraph (b)(4)(iii) of this section and upon request from ONC, make available such detailed documentation for each Predictive DSI.
                    </P>
                    <HD SOURCE="HD3">Request for Comment</HD>
                    <P>• Users of Certified Health IT and Predictive DSI Management</P>
                    <P>This request for comment included in the HTI-1 Proposed Rule (88 FR 23805-23806) focused on the DSI section, and we sought input on shared responsibilities with users related to FAVES DSIs, including intervention or model risk management during implementation (deployment) and use, as well as model validation. We welcomed technical and policy comments on this section. We received many insightful comments on this request for comment. We appreciate the input provided by commenters and may consider their input to inform a future rulemaking.</P>
                    <P>• Data Practices and Governance: Ethical, Legal, and Social Implications of Data Collection and Use</P>
                    <P>This request for comment included in the HTI-1 Proposed Rule (88 FR 2380- 23807) focused on the DSI section and related to ONC's authorities under the HITECH Act and the Cures Act with respect to adopting standards, implementation specifications, and certification criteria as part of the Program, overseeing developers of certified health IT through Conditions and Maintenance of Certification requirements, and serving in a coordinating role with respect to health IT. We welcomed technical and policy comments on this section. We received many insightful comments on this request for comment. We appreciate the input provided by commenters and may consider their input to inform a future rulemaking. We will also share relevant comments with our federal partners in the Department.</P>
                    <P>• Technical Data Standards and Data Management: Electronic Data Source, Capture, and Use</P>
                    <P>This request for comment included in the HTI-1 Proposed Rule (88 FR 23808) focused on the DSI section and how ONC can further support standardization and harmonization in these areas. We welcomed technical and policy comments on this section. We received many insightful comments on this request for comment. We appreciate the input provided by commenters and may consider their input to inform a future rulemaking.</P>
                    <HD SOURCE="HD3">xii. Public Disclosure and Availability of Summary Documentation and Corresponding Proposals for ONC-ACBs in § 170.523(f)(1)(xxi)</HD>
                    <P>
                        In the HTI-1 Proposed Rule, we proposed that a health IT developer that attested “yes” consistent with our other proposals would need to submit summary information of the IRM practices to its ONC-ACB via publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps (88 FR 23804). We also proposed a new Principle of Proper Conduct for the ONC-ACBs to require ONC-ACBs to report the proposed summary information that they received from developers of certified health IT on the Certified Health IT Product List (CHPL) for the applicable Health IT Modules. We noted our belief this new Principle of Proper Conduct is consistent with existing public disclosure requirements (
                        <E T="03">e.g.,</E>
                         45 CFR 170.523(f)(1)(xii) and § 170.523(f)(1)(xx)) under the Program and would help ensure accountability for the public availability of information. We proposed to require that this summary information be made available to ONC-ACBs via publicly accessible hyperlink by December 31, 2024.
                    </P>
                    <P>We stated that “summary information” should describe risk management practices we enumerated in our proposals for the Predictive DSIs with which a certified Health IT Module enables or interfaces within general terms. We noted that “summary information,” is not specific to any single Predictive DSI. Rather, the information pertains to the suite or portfolio of Predictive DSIs enabled by or interfaced with the certified Health IT Module. We noted that the summary information likely encompasses variation in risk management practices for different kinds of Predictive DSIs.</P>
                    <P>Similar to our policy associated with the API-focused certification criteria in § 170.315(g)(10)(viii)(B), at 88 FR 23805, we proposed that all IRM documentation be available via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps. We clarified that for the proposed IRM documentation, summary information would need to be submitted to the developer of certified health IT's ONC-ACB for review prior to issuing a certification. The availability of documentation as part of the certification process is also consistent with existing requirements for API documentation in § 170.315(g)(10)(viii)(B) (API documentation requirements were proposed in the Cures Act Proposed Rule (84 FR 7484) and finalized in the ONC Cures Act Final Rule (88 FR 25748)).</P>
                    <P>
                        To support submission of documentation, and consistent with other Principles of Proper Conduct in § 170.523(f)(1), we proposed a new Principle of Proper Conduct for IRM practice documentation in § 170.523(f)(1)(xxi) that ONC-ACBs report the information required in § 170.315(b)(11)(vii)(C) on the CHPL for the applicable certified Health IT Modules. We believe this new Principle of Proper Conduct will assist in promoting greater transparency for the 
                        <PRTPAGE P="1280"/>
                        Program and will strengthen ONC-ACB oversight regarding IRM documentation.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concern with the proposed requirement to make summary information about IRM practices available publicly because they believed it would require developers to risk revealing their intellectual property or proprietary information, increase administrative burdens, provide little value to the public, and potentially create imbalance in the marketplace. A few commenters suggested that the non-public information that the developer makes available to prospective and existing clients as part of Program certification requirements is sufficient to demonstrate adequate IRM practices. Another commenter recommended flexibility for health care providers that develop health IT solutions specific for use within their EHR platform so that disclosure of proprietary model information would be permissive.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate and understand commenters concerns about revealing proprietary information. However, we do not agree that intellectual property or trade secrets are jeopardized through publication of summary risk management information. Our final policy gives developers of certified health IT flexibility to determine what information to describe at what level of detail they feel is most appropriate. To clarify, the summary information of IRM practices requirement do not need to include public disclosure of specific information on code, model tuning, parameter or hyperparameter selection, or details on how individual input or output variables were selected or operationalized, which we understand to form the underpinnings of developers concerns related to intellectual property. We encourage developers to provide information that they determine would be useful to inform potential users of whether a model is FAVES without providing information at the level of detail that might constitute proprietary information.
                    </P>
                    <P>We recognize there may be some burden associated with making summary information of IRM practices publicly available but we believe the benefits of such transparency outweigh those burdens, especially given that we have not required generation of more detailed IRM practice information as proposed. A primary objective of our policy is to increase trust in the development and use of Predictive DSIs and this includes making summary information on risk management practices available to patients, researchers, policymakers, and other interested parties.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters expressed support for the proposed requirement to make summary information regarding IRM publicly accessible. One commenter urged ONC to include an additional requirement to require a developer to enclose an intelligible end-user fact sheet that would disclose data used for training, potential risks, concerns for bias, performance, and generalizability, at a minimum, and in clear, concise language.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments and suggestions. We note that much of the information the commenters requested is included within the source attributes listed at § 170.315(b)(11)(iv). We decline at this time to require developers to disclose source attribute information publicly, but we have finalized the requirement to publicly disclose summary of IRM practices.
                    </P>
                    <P>
                        After consideration of these comments, we have finalized requirements proposed in § 170.523(f)(1)(xxi) requiring that ONC-ACBs shall, where applicable, ensure that summary information of the IRM practices listed in paragraph § 170.315(b)(11)(vi) is submitted by the health IT developer via publicly accessible hyperlink that allows any person to access the summary information directly without any preconditions or additional steps.
                        <SU>155</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>155</SU>
                             Please visit the Program's Certified Health IT Product List (CHPL) for information about the Program's authoritative listing of all certified health IT that have been successfully tested and certified, available at 
                            <E T="03">https://chpl.healthit.gov/#/search.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">xiii. Annual Review</HD>
                    <P>
                        Finally, in the HTI-1 Proposed Rule at § 170.315(b)(11)(vi)(D), we proposed to require developers of certified health IT that attested “yes” to review annually and, as necessary, update detailed and summary documentation (88 FR 23805). We noted that we viewed the detailed documentation required as being a by-product of the proposed requirement for the developer of certified health IT to engage or employ in IRM practices. Thus, we expect that developers of certified health IT subject to this proposed requirement would review documentation associated with their IRM practices annually and, as necessary, update their documentation. Further, we noted our belief that developers of certified health IT that attested “yes” would consider risk as part of ongoing development cycles, and these risks should be assessed in a timely manner so that risk analysis documentation is up to date. Similar to the HIPAA Security Rule,
                        <SU>156</SU>
                        <FTREF/>
                         which requires covered entities and business associates to conduct ongoing risk analysis,
                        <SU>157</SU>
                        <FTREF/>
                         we proposed that developers of certified health IT with Health IT Modules that enable or interface with Predictive DSIs review their IRM practices and update their documentation as necessary.
                    </P>
                    <FTNT>
                        <P>
                            <SU>156</SU>
                             45 CFR part 160 and subparts A and C of part 164.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>157</SU>
                             45 CFR. 164.306(e) and 164.316(b)(2)(iii); see also OCR Guidance on Risk Analysis, 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html</E>
                             (noting that  “in order for an entity to update and document its security measures `as needed,' which the HIPAA Security Rule requires, it should conduct continuous risk analysis to identity when updates are needed”).
                        </P>
                    </FTNT>
                    <P>As noted in the HTI-1 Proposed Rule, we considered an annual review as a way to establish a minimum expectation for updating IRM documentation, and believed that would be good for Predictive DSIs to undergo a full validation process at some fixed interval, including updated documentation of all related activities (88 FR 23805). As noted in the HTI-1 Proposed Rule, we considered an annual review as a way to establish a minimum expectation for updating IRM documentation, and we believed that would be good practice for Predictive DSIs to undergo a full validation process at some fixed interval, including updated documentation of all related activities (88 FR 23805). While we did not propose more frequent reviews, we stated those may be appropriate for developers of certified health IT that have Health IT Modules that enable or interface with numerous or complex Predictive DSIs.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive substantive feedback regarding this requirement for annual review.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As a result, consistent with all other policy changes we have made for this final certification criterion, we have finalized requirements in § 170.402(b)(4) that developers with Health IT Modules certified to § 170.315(b)(11), starting January 1, 2025 and on an ongoing basis thereafter review and update, as necessary, information in § 170.315(b)(11)(v)(A) and (B), risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi). As noted previously (see prior comment responses in “v. Predictive Decision Support Interventions, Attestation for Predictive Decision Support Interventions”), we have determined that a supportive Maintenance of Certification requirement as part of the Assurances 
                        <PRTPAGE P="1281"/>
                        Condition of Certification is necessary to fully implement our policy objectives and proposals. We believe that this finalized policy is substantially similar to what we proposed in § 170.315(b)(11)(vii)(D). Moreover, we believe that this finalized policy maintains a substantially similar, or reduces, scope for developers of certified health IT, depending on whether they supply a Predictive DSI as part of its Health IT Module. For developers of certified health IT that would have attested “no” to our proposed attestation statement, these developers do not supply a Predictive DSI as part its Health IT Module and, therefore, do not have IRM practices or IRM summary information that needs to be reviewed and updated. For developers of certified health IT that would have attested “yes” to our proposed attestation statement, these finalized requirements are a reduction in scope given our focus on Predictive DSIs supplied by a health IT developer as part of its Health IT Module, as compared to our proposed scope of Predictive DSIs enabled or interfaced with a Health IT Module. The requirements proposed are the same as the requirements finalized for these developers of certified health IT that must review and update, as necessary, risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi).
                    </P>
                    <P>As for the finalized requirement in § 170.402(b)(4) to review and update source attribute information in § 170.315(b)(11)(v)(A) and (B), we believe this is a clearer articulation of our intention proposed at § 170.315(b)(11)(vi)(A) and (C). This annual review process clarifies expectations that developers of certified health IT must review and update, as necessary, on an ongoing basis the source attribute information that was proposed to be available for user review in § 170.315(b)(11)(vi)(A) and (C).</P>
                    <HD SOURCE="HD3">xiv. Update From Clinical Decision Support to Decision Support Intervention Criterion</HD>
                    <P>At 88 FR 23808, we proposed modifications to the Base EHR definition in § 170.102 to identify that a Health IT Module can be certified to either § 170.315(a)(9) or § 170.315(b)(11) to satisfy the definition for the period up to and including December 31, 2024. We also proposed that § 170.315(a)(9) would no longer be included as part of the Base EHR definition after December 31, 2024. Rather, only § 170.315(b)(11) and not § 170.315(a)(9) will be available as a certification criterion to satisfy the definition of Base EHR beginning January 1, 2025.</P>
                    <P>Additionally, in § 170.315(a)(9)(vi) we proposed that the adoption of § 170.315(a)(9) would expire on January 1, 2025, for purposes of the Program. Together, these proposals identified the dates when § 170.315(b)(11) replaces § 170.315(a)(9) in the Base EHR definition, and they indicated when Health IT Modules certified to § 170.315(a)(9) will need to be certified to § 170.315(b)(11) to maintain compliance with the Base EHR definition.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters were not supportive of the proposed requirement to developers of certified health IT with Health IT Modules certified to § 170.315(a)(9) who wish for those Health IT Modules to continue to meet the Base EHR definition would need to certify those Health IT Modules to § 170.315(b)(11) by December 31, 2024, and requested that the timeframe be extended due to the feasibility of implementation. Specifically, commenters requested a compliance timeframe of 24-36 months from final rule to design, program, test, certify, deploy to customers and real word test any new certification requirements for DSI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their comments regarding our proposal to modify the Base EHR definition in § 170.102 to identify the dates when § 170.315(b)(11) replaces § 170.315(a)(9) in the Base EHR definition. As part of a broader timing strategy, and in acknowledgement of the important work related to Predictive DSI transparency that is needed now, we have finalized our proposal that the reference to § 170.315(a)(9) as part of the Base EHR definition in § 170.102, thus its availability as a certification criterion in the Program, would expire January 1, 2025. We have finalized that developers of certified health IT with Health IT Modules certified to § 170.315(a)(9) who wish for those Health IT Modules to continue to meet the Base EHR definition would need to certify those Health IT Modules to § 170.315(b)(11). We also note for purposes of the Program that the certification criterion at § 170.315(a)(9) expires on January 1, 2025.
                    </P>
                    <HD SOURCE="HD3">b. Updates to Real World Testing Condition for CDS Criterion</HD>
                    <P>At 88 FR 23808-23811, we proposed to revise § 170.405(a) to include § 170.315(a)(9) within the list of certification criteria for which a developer of certified health IT with Health IT Module(s) certified to such criteria must successfully test the real world use of those Health IT Module(s) for interoperability in the type of setting in which such Health IT Module(s) would be or are marketed. As proposed, this meant that a developer of certified health IT with a Health IT Module certified to § 170.315(a)(9) would be subject to the requirements set forth in § 170.405(a) (88 FR 23808). We noted that the effects of including Health IT Modules certified to § 170.315(a)(9) in § 170.405(a) and the effect of proposing a revised version of the CDS criterion in § 170.315(b)(11) would require developers of certified health IT certified to § 170.315(a)(9) and § 170.315(b)(11) to follow the testing plans, methods, and results reporting; submission dates; and August 31 deployment deadline requirements in § 170.405(b) similar to the requirements of other applicable certification criteria listed in § 170.405(a) (88 FR 23809). We anticipated that if finalized as proposed this would mean that Health IT Modules certified to § 170.315(a)(9) would be subject to the real world testing Condition and Maintenance of Certification requirements beginning with the 2023 real world testing cycle.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters were mixed in their support and opposition to our proposal to add § 170.315(a)(9) to the list of applicable certification criteria for the real world testing Condition and Maintenance of Certification requirement in § 170.405(a) and thus requiring developers certified to § 170.315(a)(9) or § 170.315(b)(11) to participate in real world testing plan and results submission. Commenters that did not support including § 170.315(a)(9) in the list of applicable criteria for real world testing Condition and Maintenance of Certification requirements stating that it would be infeasible, and a poor investment of time and resources given the possible timing of this final rule publication in conjunction with requirements for 2024 real world testing plan submissions in November of 2023. Commenters stated that it would create significant developer burden to meet this requirement for a criterion that developers could not certify to after December 31, 2024. Many of these commenters instead said we should limit real world testing requirement to developers of certified health IT with Health IT Module(s) certified to § 170.315(b)(11). Commenters suggested that by only including § 170.315(b)(11) then ONC and developers could focus resources on a revised criterion instead of a retired criterion. Commenters also recommended a phased approach for the inclusion of Predictive DSI into real 
                        <PRTPAGE P="1282"/>
                        world testing given the burden on developers to implement other proposals in the rule, notably the new Insights Condition and Maintenance of Certification requirements.
                    </P>
                    <P>Commenters who were supportive of the proposal to add § 170.315(a)(9), thus requiring developers certified to § 170.315(b)(11) to participate in real world testing, stated that it would have the benefit of testing predictive models in a diverse range of real world clinical settings, thereby creating a more accurate, comprehensive, and contextual understanding of a model's performance. Commenters noted that including CDS will help ensure implementation of the CDS Criterion, future certification criteria, and other elements discussed in this rule are effective, efficient, minimally burdensome, and beneficial, and would ensure intended performance in practice. One commenter stated that adding CDS to real world testing will give developers an opportunity to determine if the user community is using their interventions, and if so, the ability to determine how the interventions are being used. Lastly, one commenter believed that testing decision support intervention technology and predictive models successfully for real world use enhances interoperability and patient care experience in which certified Health IT Modules would be marketed.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate comments regarding our proposal to revise § 170.405(a) to include § 170.315(a)(9). Given the mixed support from commenters and finalization of our policy to replace § 170.315(a)(9) with § 170.315(b)(11) as of January 1, 2025, we have not finalized our proposal to modify § 170.405(a) to include Health IT Modules certified to § 170.315(a)(9). We agree with commenters that requiring developers of certified health IT with Health IT Modules certified to § 170.315(a)(9) to engage in real world testing for only the period of time before the revised criterion expires is unnecessary. We continue to believe there is value for developers of certified health IT with Health IT Modules certified to § 170.315(a)(9) to demonstrate how their support of evidence-based CDS and linked referential CDS positively impacts patient care through real world testing plans and results; however, we think it would be more important for developers of certified health IT to spend time and resources conforming to requirements in § 170.315(b)(11) and § 170.402(b)(4) by January 1, 2025.
                    </P>
                    <P>We note that because all criteria in § 170.315(b) are already subject to real world testing requirements in § 170.405, Health IT Modules certified to § 170.315(b)(11) prior to August 31, 2024, would need to, among other requirements, address each of the elements in § 170.405(b)(1)(iii)(A) through (G) in their real world testing plans by December 15, 2024, and submit results based on those plans no later than March 15, 2026.</P>
                    <P>We appreciate those commenters who supported our proposals for real world testing because it would have various benefits for more accurate, comprehensive, and contextual understanding of a model's performance. We also appreciate the commenters that stated how real-world testing will give developers an opportunity to determine if the user community is using their interventions, and if so, the ability to determine how the interventions are being used. We agree and we encourage developers of certified health IT to consider ways to demonstrate validity or fairness of Predictive DSIs in local data as a means to fulfill the requirements for real world testing plans and results.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A minority of commenters did not support including either § 170.315(a)(9) or § 170.315(b)(11) in real world testing and stated neither certification criterion appropriately fit the stated intent for the scope of Real world Testing Condition and Maintenance of Certification. One commenter recommended including § 170.315(a)(9) in real world testing, with the proposed updates, but only if ONC would keep § 170.315(a)(9) as a certification criterion and add § 170.315(b)(11) as a separate certification criterion, noting that requiring real world testing for Predictive DSI immediately after development and implementation is overly burdensome for developers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments and we have not finalized our proposal to modify § 170.405(a) to include Health IT Modules certified to § 170.315(a)(9). We note that certification criteria at § 170.315(b) are already subject to real world testing requirements identified in § 170.405; thus, Health IT Modules certified to § 170.315(b)(11) will be subject to the same requirements currently applied to Health IT Modules certified to § 170.315(b)(1), for example. We believe real world testing would not be overly burdensome with the implementation of the DSI requirements under § 170.315(b)(11).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters questioned the logistics of real world testing CDS and DSI criteria and sought clarity on how the proposed real world testing plan will be assessed. Specifically, one commenter sought clarity on how real world testing would impact a health plan's existing operations. One commenter suggested that certification testing could be accomplished using a test data set that incorporates synthetic patient records containing a wide range of demographic and health condition information, including rare diseases and conditions, noting that DSI training and testing data should be developed in collaboration with provider, patient, research, and health IT partners and made available to all parties in a standardized, computable format. In the interest of program flexibility, one commenter suggested that real world testing of CDS should allow for some types of survey or questionnaire form for providers to offer feedback on the value and use of CDS in the EHR rather than trying to capture analytics or metrics on CDS use from the EHR as developers are required to do with other real world testing criteria.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We note that we did not propose any changes to the requirements of real world testing plans and results submission, which are currently described in § 170.405(b)(1)-(2). We also invite readers to review discussion in the ONC Cures Act Final Rule at 85 FR 25766 and visit the numerous resources we have developed to support ongoing implementation of the real world testing Condition and Maintenance of Certification requirements at 
                        <E T="03">https://www.healthit.gov/topic/certification-ehrs/real-world-testing.</E>
                    </P>
                    <HD SOURCE="HD3">6. Synchronized Clocks Standard</HD>
                    <P>We proposed at 88 FR 23811 to remove from 45 CFR 170.210(g) the current named specification for clock synchronization, which is Network Time Protocol (NTP v4 of RFC 5905). However, we proposed to amend 45 CFR 170.210(g) so that Health IT Modules certified to applicable certification criteria continue to utilize any Network Time Protocol (NTP) standard that can ensure a system clock has been synchronized and meets time accuracy requirements. The applicable certification criteria that either reference the NTP standard, revised in § 170.210(g), or cross-reference a provision that references § 170.210(g), include § 170.315(d)(2), § 170.315(d)(3), § 170.315(d)(10), and § 170.315(e)(1) (88 FR 23811).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters, including health information technology companies, consumer and patient advocacy groups, health IT expert organizations, and professional trade 
                        <PRTPAGE P="1283"/>
                        associations, uniformly agreed with our proposal to remove the named standard in § 170.210(g) and instead require the date and time recorded utilize a system clock that has been synchronized using any NTP standard. Several commenters welcomed the flexibility offered by this approach to use updated versions of NTP or specified versions of NTP, such as Microsoft's MS-SNTP. One commenter noted support for our proposal but urged consistency across organizational networks and systems to ensure that the same network time protocol is used across all servers and platforms.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the commenters' support for this proposal. We have finalized the changes as proposed, including the removal of a named standard in § 170.210(g), but we will require Health IT Modules to utilize a system clock that has been synchronized using any NTP standard.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A health IT expert organization requested ONC comment on the NTP test procedure by either explicitly removing the demonstration requirement or describing a test procedure to demonstrate time server accuracy to accommodate a variation in time services used.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for the comment. While the request is outside the scope of this final rule because conformance methods, including testing procedures, are not determined as part of notice and comment rulemaking, we will consider updating the test procedures in the future.
                    </P>
                    <HD SOURCE="HD3">7. Standardized API for Patient and Population Services</HD>
                    <P>In the HTI-1 Proposed Rule, we proposed to reorganize § 170.215 to delineate the purpose and scope more clearly for each type of standard or implementation specification (88 FR 23812). We refer readers to the HTI-1 Proposed Rule (88 FR 23812) for additional background history. We proposed to revise the structure of § 170.215 as follows:</P>
                    <P>Application Programming Interface Standards.</P>
                    <P>
                        (a) 
                        <E T="03">API base standard.</E>
                    </P>
                    <P>
                        (b) 
                        <E T="03">API constraints and profiles.</E>
                    </P>
                    <P>
                        (c) 
                        <E T="03">Application access and launch.</E>
                    </P>
                    <P>
                        (d) 
                        <E T="03">Bulk export and data transfer standards.</E>
                    </P>
                    <P>
                        (e) 
                        <E T="03">API authentication, security, and privacy.</E>
                    </P>
                    <P>
                        <E T="03">Comment.</E>
                         We received one comment supporting the revision of the structure of the API related standards.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for their support. We have finalized the revised structure of § 170.215 as proposed. This restructuring will impact cross-references in the certification criterion at § 170.315(g)(10) in several subparagraphs, including § 170.315(g)(10)(i)(A) and (B); § 170.315(g)(10)(ii); § 170.315(g)(10)(iv)(A) and (B); § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) and (
                        <E T="03">ii</E>
                        ); § 170.315(g)(10)(v)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) and (
                        <E T="03">ii</E>
                        ); § 170.315(g)(10)(v)(B); and § 170.315(g)(10)(vii).
                    </P>
                    <HD SOURCE="HD3">a. Native Applications and Refresh Tokens</HD>
                    <P>
                        In an interim final rule (IFR) published on November 4, 2020 (85 FR 70064), we addressed an ambiguity regarding how our refresh token requirements, in § 170.315(g)(10)(v)(A), would apply to “native applications.” 
                        <SU>158</SU>
                        <FTREF/>
                         In response to public feedback in the IFR and subsequent interaction with interested parties, a history of which can be found in the HTI-1 Proposed Rule (88 FR 23812), we proposed in the HTI-1 Proposed Rule to remove mention of “applications capable of storing a client secret” from § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ) and § 170.315(g)(10)(v)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ), as well as to revise § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ) to state, “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)” (88 FR 23813). We also proposed to revise § 170.315(g)(10)(v)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ) to state, “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)” (88 FR 23813). We stated that these proposed revisions would better reflect a Health IT Module's obligation for first time and subsequent connection refresh tokens using concepts familiar to industry and according to the HL7 FHIR SMART Application Launch Framework Implementation Guide (IG). We noted that existing requirements for Health IT Modules to issue a refresh token to native applications, consistent with § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">iii</E>
                        ), remained unchanged.
                    </P>
                    <FTNT>
                        <P>
                            <SU>158</SU>
                             According to IETF RFC 6749, “native applications are “clients installed and executed on the device used by the resource owner (
                            <E T="03">i.e.,</E>
                             desktop application, native mobile application).” See IETF RFC 6749: 
                            <E T="03">https://tools.ietf.org/html/rfc6749.</E>
                        </P>
                    </FTNT>
                    <P>We also stated in the HTI-1 Proposed Rule that we would continue to monitor implementation of § 170.315(g)(10), engage with the standards development community, and provide information through existing ONC Certification Companion Guides (CCGs), the ONC API Resource Guide, and other educational materials.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters expressed support for our proposal to revise § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ) and (
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ) to reference the “confidential app” profile defined in the HL7 FHIR SMART Application Launch Framework IG as part of our refresh token support requirements. Several of these commenters expressed appreciation for our reference to an industry standard and noted the important role of this standard for driving consistent implementations and interoperability.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. We have finalized our revisions to § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ) and (
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ) as proposed.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters raised concerns around the impacts to app developers of breaking API changes, particularly changes that affect refresh token validity. These commenters suggested requirements that app developers be given advance notification of upcoming breaking changes that affect refresh tokens.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these commenters' concerns and suggestions. We remind commenters of the scope of our revisions to § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ) and (
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ) in this final rule, and specifically note that our revisions do not change certain previously finalized requirements around refresh tokens, namely that Health IT Modules certified to § 170.315(g)(10) must issue refresh tokens valid for a period of no less than three months.
                        <SU>159</SU>
                        <FTREF/>
                         We also remind commenters of our existing API Conditions and Maintenance of Certification requirements at 45 CFR 170.404, which apply to developers of certified health IT with Health IT Modules certified to § 170.315(g)(10). Specifically, at § 170.404(a)(4)(iii), we have “service and support obligations” that Certified API Developers must abide by. These obligations include requirements for Certified API Developers to “make reasonable efforts to maintain the compatibility of its certified API technology and to otherwise avoid disrupting the use of certified API technology in production environments” by API Users. While we appreciate the specific suggestions from commenters for added requirements, we decline to add these requirements in this final rule. In the circumstance 
                        <PRTPAGE P="1284"/>
                        where a Certified API Developer must make a change to their technology that affects refresh token validity, we expect that the Certified API Developer abide by the obligations referenced above to enable the continued and effective production use of their certified API technology.
                    </P>
                    <FTNT>
                        <P>
                            <SU>159</SU>
                             See § 170.315(g)(10)(v)(A)(
                            <E T="03">1</E>
                            )(
                            <E T="03">ii</E>
                            ), (
                            <E T="03">iii</E>
                            ), and (
                            <E T="03">2</E>
                            )(
                            <E T="03">ii</E>
                            ) in 85 FR 70083.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters suggested that refresh tokens for non-patient facing applications should be reviewed on a case-by-case basis for security reasons. One commenter asked that we clarify that apps may, at times, be required to request a new token with new access scopes instead of using a refresh token and that this is not a violation of our refresh token policies. Another commenter suggested that we change the requirements for the duration of refresh tokens and that three months is not always appropriate in all cases.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these suggestions from commenters. We do not agree that we should include separate requirements for refresh tokens that apply only in non-patient facing application use cases at this time. We remind this commenter of what we stated in the ONC Cures Act Final Rule at 85 FR 25746—25747 when responding to commenters who similarly raised security concerns and suggested we finalize different requirements for refresh tokens based on patient versus non-patient facing application use cases. Those sections of the ONC Cures Act Final Rule also clarify what implementers of § 170.315(g)(10)-certified Health IT Modules are allowed to do regarding refresh token length and clarify what practices we see as restricted. We stated in the ONC Cures Act Final Rule that “[r]efresh tokens are commonly used in healthcare and other industries” and that “implementers of § 170.315(g)(10)-certified Health IT Modules are not prohibited from changing the length of refresh tokens for users of the API including patients and providers to align with their institutional policies.” We also stated that “implementers of § 170.315(g)(10)-certified Health IT Modules should be mindful of information blocking provisions applicable to them and that requiring patients to re-authenticate and re-authorize at a high frequency could inhibit patient access and implicate information blocking” (85 FR 25747).
                    </P>
                    <P>
                        Regarding duration of refresh tokens, we again remind commenters of what we clarified in the ONC Cures Act Final Rule where we noted that “we believe a refresh token valid for a period of three months is sufficient to balance persistent access and security concerns” (85 FR 25747). We also stated that implementers (
                        <E T="03">e.g.,</E>
                         hospitals) “of § 170.315(g)(10)-certified Health IT Modules are not prohibited from changing the length of refresh tokens for users of the API, including patients and providers, to align with their institutional policies. Further, implementers of § 170.315(g)(10)-certified Health IT Modules are not prohibited from implementing their § 170.315(g)(10)-certified Health IT Modules in accordance with their organizational security policies and posture, including by instituting policies for re-authentication and re-authorization (
                        <E T="03">e.g.,</E>
                         providers and/or patients could always be required to re-authenticate and re-authorize after a set number of refresh tokens have been issued)” (85 FR 25747). Further, we clarify that § 170.315(g)(10)-certified Health IT Modules may require a new authorization request from an application to provision that application with scopes not already granted.
                    </P>
                    <P>
                        In acknowledgement of the comments received, we have finalized our requirements in § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ) and (
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ) to reference the “confidential app” profile defined in the HL7 FHIR SMART Application Launch Framework as proposed.
                    </P>
                    <HD SOURCE="HD3">b. FHIR United States Core Implementation Guide Version 5.0.1</HD>
                    <P>In the HTI-1 Proposed Rule, 88 FR 23813 to 238144, we included a proposal to adopt the FHIR US Core IG v5.0.1 in § 170.215(b)(1)(ii) and incorporate it by reference in § 170.299. We noted that based on the annual US Core release cycle, the FHIR US Core IG v6.0.0 would likely be published between the release of the HTI-1 Proposed Rule and our finalization of this final rule. Assuming the FHIR US Core IG v6.0.0 was published prior to the release of this final rule, we stated that we would consider adopting v6.0.0 rather than v5.0.1. We stated our belief that the FHIR US Core IG v6.0.0 would support the data elements and data classes in USCDI v3, which we also proposed to adopt in the HTI-1 Proposed Rule.</P>
                    <P>In addition, we proposed to update some of the cross-references to the FHIR US Core IG v3.1.1 in § 170.215(a)(2) in § 170.315(g)(10)(i)(A) and (B), (ii)(A) and (iv)(A) to instead refer to FHIR US Core IG v5.0.1. Finally, we proposed to restructure the standards in § 170.215 to better categorize API standards and to enable simultaneous use of different versions of IGs for a set period. For example, we proposed categorizing the US Core IG v3.1.1 in § 170.215(b)(1)(i) as part of a group of standards for constraining and profiling data elements, and we proposed that the adoption of this standard would expire on January 1, 2025. We proposed to include the US Core IG v5.0.1 in this same group in § 170.215(b)(1)(ii).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters overwhelmingly supported our proposal to advance the version of the FHIR US Core IG included in § 170.215 and incorporated by reference in § 170.299. Most of the commenters specifically voiced support for including the FHIR US Core IG v6.0.0, which was published in May 2023 and supports the data elements and data classes in USCDI v3. We did not receive any comments in favor of adopting the FHIR US Core IG v5.0.1 rather than v6.0.0. Commenters noted that the FHIR US Core IG v6.0.0 aligns with our proposals elsewhere in the HTI-1 Proposed Rule, including our proposals to adopt USCDI v3 and the SMART v2 IG.
                    </P>
                    <P>We received only one comment in opposition to the proposal to advance the version of the FHIR US Core IG, which expressed concerns about the limited amount of time for developers to test and implement v5.0.1. While still supportive of advancing the version of the FHIR US Core IG, several other commenters also expressed concerns about the timelines for adoption of the latest version. These commenters urged ONC to acknowledge the development time and effort required to support a newer version of the US Core FHIR IG and consider extending the deadline for certification to a newer version.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their support. The HL7 standards development community published FHIR US Core 6.0.0 in May 2023. As anticipated, FHIR US Core 6.0.0 added new and updated FHIR profiles to represent new data elements and classes included in USCDI v3. We considered adopting FHIR US Core 5.0.1 and FHIR US Core 6.0.0 and using the Standards Version Advancement Process (SVAP) to enable developers of certified health IT to use FHIR US Core 6.1.0 to certify Health IT Modules that require support of the USCDI. However, we concluded that this would be insufficient to achieve our policy objectives for improved interoperability and lead to misalignment in the marketplace. This is because use of the SVAP by developers of certified health IT is voluntary and experience to-date indicates that a minority of developers of certified health IT choose to avail their Health IT Modules to use newer standards. Adopting FHIR US Core 6.1.0 establishes a consistent baseline across all Health IT Modules certified to 
                        <PRTPAGE P="1285"/>
                        criteria that reference the USCDI and provides clarity to developers of certified health IT regarding which version of the US Core IG they are expected to use in support of USCDI v3 and which version they can expect to encounter when interacting with other actors in the health IT ecosystem, industry-wide.
                    </P>
                    <P>After the publishing of FHIR US Core 6.0.0, HL7 found errors with how the guide implemented data elements in USCDI v3 and had to make updates to the specification to align with USCDI v3 and ensure that USCDI v3 can be implemented in Health IT Modules. Adopting FHIR US Core 6.1.0 is necessary for developers of certified health IT to have appropriate implementation guidance to meet the criteria adopted in this final rule that reference USCDI v3. Based on public comments on this and prior rulemakings, we believe that the health IT industry, healthcare standards developers, and health care providers expect and support ONC making such determinations so that the adopted version of standards are the most up-to-date available and are feasible for real world implementation (see, for example, 85 FR 25677 and 25708).</P>
                    <P>We have finalized the adoption of the FHIR US Core 6.1.0 in § 170.215 and incorporated it by reference in § 170.299. We have also finalized our proposal to restructure the standards in § 170.215 and adopted the FHIR US Core 6.1.0 at § 170.215(b)(1)(ii). Likewise, we have finalized our proposal to categorize the FHIR US Core IG v3.1.1 in § 170.215(b)(1)(i) as part of a group of standards for constraining and profiling data elements and have finalized our proposal that the adoption of this standard would expire on January 1, 2026. With regard to concerns about compliance dates, we refer readers to the discussion in section II.C (General Comments on the HTI-1 Proposed Rule) of this final rule.</P>
                    <HD SOURCE="HD3">c. FHIR Endpoint for Service Base URLs</HD>
                    <P>In the ONC Cures Act Final Rule, we finalized API Maintenance of Certification requirements in 45 CFR 170.404(b)(2) which contain a specific provision requiring Certified API Developers, for Health IT Modules certified to the certification criterion in § 170.315(g)(10), to publicly publish certain “service base URLs”—otherwise known as “endpoints”—for all their customers and in a machine-readable format at no charge (85 FR 25764—25765). These electronic endpoints are the specific locations on the internet that make it possible for apps to access EHI at the patient's request.</P>
                    <P>As we developed these service base URL publication requirements in the ONC Cures Act Final Rule, we acknowledged the importance of industry alignment and standardization in this area by indicating that we “strongly encourage API Technology Suppliers, health care providers, HINs and patient advocacy organizations to coalesce around the development of a public resource or service from which all interested parties could benefit” (84 FR 7494). We ultimately did not adopt specific standards for the publication format of these service base URLs in the ONC Cures Act Final Rule to provide industry an opportunity to coalesce on specifications. We finalized § 170.404(b)(2) to require that Certified API Developers must make their service base URLs freely accessible and in a machine-readable format at no charge (85 FR 25765).</P>
                    <P>
                        However, since the ONC Cures Act Final Rule was published, we have found that developers with publicly discoverable endpoint lists have defined their own bespoke publication approaches and unique formats. This variability across developers of certified health IT in the format they are using to publish their service base URLs indicates the industry has not coalesced around a common framework or approach. Research conducted through ONC's Lantern Project confirms this variability among developers of certified health IT, which is hindering maturation of a vibrant app ecosystem for patients and the healthcare community,
                        <SU>160</SU>
                        <FTREF/>
                         a primary objective within the Federal Health IT Strategic Plan.
                        <SU>161</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>160</SU>
                             
                            <E T="03">https://www.healthit.gov/buzz-blog/healthit-certification/shining-a-light-on-fhir-implementation-progress-toward-publishing-fhir-endpoints.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>161</SU>
                             See objective 1b in the 2020-2025 Federal Health IT Strategic Plan at 
                            <E T="03">https://www.healthit.gov/topic/2020-2025-federal-health-it-strategic-plan.</E>
                        </P>
                    </FTNT>
                    <P>
                        The inconsistent implementation of our service base URL requirement has also rendered important data meant to facilitate connections to endpoints difficult to access.
                        <SU>162</SU>
                        <FTREF/>
                         Specifically, the organization details of the API Information Source associated with a service base URL is not always available, and even when available, is not always available in a format that can be readily used. Patient-facing apps require access to these service base URLs to provide patients access to information maintained by specific provider organizations that deploy certified API technology (
                        <E T="03">i.e.,</E>
                         API Information Sources). Without standardized formats and an ability to search for service base URLs, patients are hindered in their ability to find which service base URL(s) refer to their provider. Similar barriers exist for others involved in healthcare seeking to leverage apps for interoperability.
                    </P>
                    <FTNT>
                        <P>
                            <SU>162</SU>
                             
                            <E T="03">https://www.healthit.gov/news/events/onc-lantern-workshop.</E>
                        </P>
                    </FTNT>
                    <P>
                        Additionally, it is difficult to map multiple, unique organizations to service base URLs. Experience to-date indicates that the name of the organization associated with a service base URL is typically formatted as free text (
                        <E T="03">i.e.,</E>
                         String). A single String is unable to represent the complexity of healthcare systems, where a system can contain many subsystems, or where a FHIR API URL can support a set of systems. Including all organizations that are serviced by a service base URL is important for discovery of which service base URL serves a particular health care provider, which in turn would allow API users to access relevant EHI through that service base URL. Having all healthcare organizations serviced by the service base URL accessible and in a standardized format would help app developers easily fetch information to enable patients and other users to access, exchange, and use information.
                    </P>
                    <P>To address the inconsistencies in service base URL publication and challenges with mapping, we proposed in the HTI-1 Proposed Rule to revise the requirement in § 170.404(b)(2) to include new data format requirements (88 FR 23814). We anticipated that these new specifications would establish standards for industry adoption and better facilitate patient access to their health information. In the revised § 170.404(b)(2), we also proposed to incorporate the following existing requirements in § 170.404(b)(2)(i) and (ii): a Certified API Developer must publish service base URLs “[f]or all of its customers regardless of whether the Health IT Modules certified to § 170.315(g)(10) are centrally managed by the Certified API Developer or locally deployed by an API Information Source;” and publish these service base URLs “at no charge” as part of proposed § 170.404(b)(2). We proposed that Certified API Developers publish these standardized details by December 31, 2024.</P>
                    <P>
                        In § 170.404(b)(2)(i), we proposed to require that service base URLs must be published in “Endpoint” resource format according to the FHIR standard adopted in § 170.215(a) (88 FR 23814). Additionally, in § 170.404(b)(2)(ii) and subparagraphs § 170.404(b)(2)(ii)(A) and § 170.404(b)(2)(ii)(B), we proposed to require that organization details such as name, location, and provider identifiers 
                        <PRTPAGE P="1286"/>
                        (
                        <E T="03">e.g.,</E>
                         National Provider Identifier (NPI), CMS Certification Number (CCN), or health system ID) for each service base URL must be published in US Core “Organization” resource format according to the implementation specifications adopted in § 170.215(b)(1) (we note that elsewhere in this final rule, in section III.C.7.b, we discuss the proposal to move US Core IGs to § 170.215(b)(1)), with the “Organization.endpoint” element referencing the service base URLs managed by this organization.
                    </P>
                    <P>
                        We proposed the Endpoint and Organization resource formats because they are based on the FHIR Release 4 and US Core IG industry standards that are already adopted for use in the Program in § 170.315(g)(10). We specifically proposed the FHIR “Endpoint” resource because it is used for representing technical endpoint details and contains a required “address” element that, according to the FHIR R4 standard, contains “the technical base address for connecting to this endpoint.” 
                        <SU>163</SU>
                        <FTREF/>
                         We noted that Certified API Developers would be able to populate this element, in each of their published “Endpoint” resources, with a service base URL that can be used by patients to access their EHI.
                    </P>
                    <FTNT>
                        <P>
                            <SU>163</SU>
                             
                            <E T="03">https://hl7.org/fhir/R4/endpoint.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        We additionally proposed the US Core “Organization” resource because it can be used to represent important contextual information around a service base URL (88 FR 23814 through 23815). We noted that the US Core “Organization” resource contains an optional “endpoint” element that can be used to reference “technical endpoints providing access to services operated for the organization.” 
                        <SU>164</SU>
                        <FTREF/>
                         To standardize a link between published “Endpoint” resources and organization details relating to the organization that services these endpoints, we proposed to require, in § 170.404(b)(2)(ii)(A), that this optional “endpoint” element be populated on publicly published “Organization” resources and that they reference the “Endpoints” managed by the organization. We noted that “publicly published” meant that the information is made publicly available and noted that ONC will host a link to developers' service base URL list on the Certified Health IT Product List (CHPL) or another website hosted by ONC. We stated that this information would give the public a standard way of knowing how published “Endpoint” and published “Organization” resources are linked and which organization details apply to which service base URLs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>164</SU>
                             
                            <E T="03">https://www.hl7.org/fhir/organization.html.</E>
                        </P>
                    </FTNT>
                    <P>Additionally, we noted in the HTI-1 Proposed Rule that the US Core “Organization” resource contains a “mandatory” element called “name” that contains a “name used for the organization” (88 FR 23815). In addition to this required element, we proposed in § 170.404(b)(2)(ii)(B) to require Certified API Developers to make available “must support” elements of organization location and provider identifier(s) using the US Core “Organization” resource. An organization's location could be an address that is populated in the “address” element of the US Core “Organization” resource; and a provider identifier could be a National Provider Identifier (NPI), Clinical Laboratory Improvement Amendments (CLIA) number, or other health system ID populated in the “identifier” element. We noted that this information helps contextualize service base URLs and enables application developers to more easily and consistently provide patients access to their electronic health information.</P>
                    <P>
                        Finally, we proposed, in § 170.404(b)(2)(iii), requirements for collection and maintenance of Endpoint and organization resources. Specifically, in § 170.404(b)(2)(iii)(A), we proposed to require that these resources be collected in a “Bundle” resource, according to the FHIR standard adopted in § 170.215(a), that the Certified API Developer would publicly publish (88 FR 23815). According to the FHIR specification, a “Bundle” acts as “a container for a collection of resources” and is widely used in use cases, such as returning search results and grouping resources as part of a message exchange.
                        <SU>165</SU>
                        <FTREF/>
                         Given the broad use of the “Bundle” resource throughout the FHIR specification (
                        <E T="03">e.g.,</E>
                         FHIR search), we noted in the HTI-1 Proposed Rule our expectation that most FHIR clients and FHIR application developers would be familiar with the “Bundle” resource and be able to parse “Bundle” resources electronically and extract relevant information from them for use in their application. Alternatively, we considered a different format for requiring that the Endpoint and Organization resources be collected for publication. We also considered the Newline Delimited JSON (ndjson) format (88 FR 23815). According to the ndjson specification, this format is convenient for publishing “structured data that may be processed one record at a time.” 
                        <SU>166</SU>
                        <FTREF/>
                         The ndjson format is an efficient way for machines to parse large amounts of data given that the entire file does not need to be read into memory before parsing. As we noted in the HTI-1 Proposed Rule, we expect that these “Endpoint” and “Organization” JSON resource lists may be large, depending on the developer of certified health IT's client base. We noted our expectation that most Certified API Developers would be familiar with this format because it is included as an underlying standard in the FHIR Bulk Data Access IG required for certification to § 170.315(g)(10). Given the simplicity of the ndjson standard, we also noted our expectation that most FHIR clients and FHIR application developers would easily be able to parse ndjson files electronically and extract relevant information from them for use in their application.
                    </P>
                    <FTNT>
                        <P>
                            <SU>165</SU>
                             
                            <E T="03">http://hl7.org/fhir/R4/bundle.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>166</SU>
                             
                            <E T="03">http://ndjson.org/.</E>
                        </P>
                    </FTNT>
                    <P>We also proposed, in § 170.404(b)(2)(iii)(B), that Certified API Developers review Endpoint and Organization resources quarterly and, as necessary, update the information (88 FR 23815). We recognized that as customers upgrade and install new health IT, data provided in the Endpoint and Organization resources will change. In the HTI-1 Proposed Rule, we noted that a one-time publication of the developer's current list of endpoints for active customers upon certification to the § 170.315(g)(10) criterion will only meet initial certification requirements, and we proposed to establish in § 170.404(b)(2)(iii)(B) a requirement that Certified API Developers maintain this information over time. We also noted that failure to maintain the service base URLs and ensure the associated organization information remains up to date and free of errors or defects on a quarterly basis would be considered a violation of this Condition and Maintenance of Certification requirement and may result in corrective action. We clarified that any endpoint or organization information that is out of date, incomplete, or otherwise unusable for more than 90-days would be considered in violation of this proposed requirement.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters support the continued development and standardization of publication formats for FHIR “service base URLs” otherwise known as “endpoints,” noting that standardization would better facilitate interoperability and address challenges that exist in operationalizing connections to FHIR servers for facilitating patient access. Many of these supportive commenters cautioned that our proposal does not align with the direction of industry and one 
                        <PRTPAGE P="1287"/>
                        commenter raised a particular concern that our proposal is not based in implementation experience and has not been informed by a draft implementation guide. Another commenter noted that since we are proposing that the “endpoint” element in the US Core “Organization” resource be used to reference FHIR R4 “Endpoint” resource(s), we should make specific and clear reference to the applicability of FHIR R4 and its detailed standards on Endpoint. Most of these commenters also offered suggestions on how we should change our proposal by citing the Argonaut implementation guide for Patient-access Brands as standard and the industry driven approach we should consider referencing for this endpoint publication use case.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their support of the continued development in this space and suggestions for improvement. The “Patient-access Brands” conceptual model, developed by the FHIR community through the Argonaut Project, has advanced significantly since publication of the HTI-1 Proposed Rule. A connectathon, which is an event where the FHIR community gathers and tests emerging FHIR standards, was held in May 2023 and it included developers of certified health IT and app developers who tested the real-world feasibility of the Patient-access Brands model.
                        <SU>167</SU>
                        <FTREF/>
                         Additionally, at the September 2023 HL7 Working Group Meeting, the FHIR community discussed and finalized new changes to the Patient-access Brands model.
                        <SU>168</SU>
                        <FTREF/>
                         Currently, the Patient-access Brands model is incorporated into a section of the continuous build draft version of the SMART App Launch IG.
                        <SU>169</SU>
                        <FTREF/>
                         This indicates that the Patient-access Brands model is now a draft specification and is on track for publication in a future version of the SMART App Launch IG.
                    </P>
                    <FTNT>
                        <P>
                            <SU>167</SU>
                             More information on this connectathon can be found at 
                            <E T="03">https://confluence.hl7.org/pages/viewpage.action?pageId=90350859#EndpointCallNotes-2023-5-312-5pET:Connectathon.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>168</SU>
                             See 
                            <E T="03">https://jira.hl7.org/browse/FHIR-42134.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>169</SU>
                             
                            <E T="03">https://build.fhir.org/ig/HL7/smart-app-launch/branches/pab/brands.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        We agree with commenters that the Patient-access Brands specification is a key standardized approach for the endpoint publication use case and we are committed to aligning our requirements with industry efforts. In the HTI-1 Proposed Rule, our proposal generally aligned with the current draft Patient-access Brands specification by calling for the use of “Organization” and “Endpoint” FHIR resources for representing endpoints (
                        <E T="03">e.g.,</E>
                         service base URLs) and corresponding organization (
                        <E T="03">e.g.,</E>
                         API Information Source) details in a standardized format.
                    </P>
                    <P>
                        Additionally, in the HTI-1 Proposed Rule, our proposal, similarly to the current draft of Patient-access Brands specification, called for the use of the “endpoint” element in the US Core “Organization” resource for linking “Endpoint” resources and organizational details relating to the organization that services this endpoint.
                        <SU>170</SU>
                        <FTREF/>
                         However, our proposal in the HTI-1 Proposed Rule is not an exact match of the underlying construct defined in the Patient-access Brands specification. One key difference that could result in incompatibilities between our requirements and the industry led efforts in the Patient-access Brands specification is that we referenced the US Core profile of the base FHIR “Organization” resource, while the Patient-access Brands specification includes its own custom profile of the base FHIR “Organization” resource. Both profiles are based off the base FHIR “Organization” resource, but they each contain their own sets of constraints to best match their use cases.
                    </P>
                    <FTNT>
                        <P>
                            <SU>170</SU>
                             During the public comment period for the HTI-1 Proposed Rule, the draft Patient-access Brands specification called for the use of the “managiningOrganization” element in the “Endpoint” resource for linking “Endpoint” and “Organization” resources. At the September 2023 HL7 Working Group Meeting, occurring after the comment period for the HTI-1 Proposed Rule closed, the FHIR community approved a change to use the “endpoint” element in the “Organization” resource instead of the “managiningOrganization” element in the “Endpoint” resource for linking “Endpoint” and “Organization” resources. See 
                            <E T="03">https://jira.hl7.org/browse/FHIR-42134.</E>
                        </P>
                    </FTNT>
                    <P>Based on commenter feedback, we do not believe it is necessary for us to impose US Core level “Organization” resource constraints and reference the FHIR “Organization” resource via the US Core IG at this time. We agree with the commenter who recommended a specific and clear reference to the applicability of FHIR R4. We realize that we introduced some unnecessary confusion by referencing two separate but related standards, namely FHIR R4 and US Core, in separate paragraphs of our proposed criterion updates in § 170.404(b)(2). To simplify our requirements and make a more specific and clear reference to FHIR R4, we believe it is necessary to reference one standard, namely FHIR R4. We also agree with the many commenters who emphasized the importance of considering and not conflicting with the standards developed by the FHIR community for the endpoint publication use case, and we believe that referencing the more general FHIR R4 standard for our Program reduces the risk of conflicting requirements.</P>
                    <P>To generalize our proposal, respond to commenter feedback, and to align our requirements with emerging industry standards for the endpoint discovery use case, we have finalized a modified version of our proposed requirements at § 170.404(b)(2). We have modified the standard referenced in § 170.404(b)(2)(ii) to require the use of the base FHIR “Organization” resource instead of the more constrained US Core-profiled version of the base FHIR “Organization” resource. Specifically, we have revised § 170.404(b)(2)(ii) to reference the standard adopted in § 170.215(a). We emphasize that subparagraphs of finalized § 170.404(b)(2)(ii)(A) and (B) remain largely unchanged, meaning that Certified API Developers will still be required to reference “Endpoint” resources using the “endpoint” element in the “Organization” FHIR resource and will still be required to publish organization details such as name, location, and facility identifier. With this modification, we have finalized a policy that is less prescriptive than what we proposed. By referencing the base FHIR “Organization” resource, instead of the US Core-profiled “Organization” resource, Certified API Developers have more flexibility to support the “Organization” resource without minimal element constraints and no elements are marked as “must support.” We note that when proposing the US Core “Organization” resource profile, we referenced certain mandatory and “must support” elements contained in that profile, including “address,” “name,” and “identifier.” We did not adopt these constraints; rather, we are leaving it up to the Certified API Developer to determine how best to publish the required organization details using the base FHIR standard instead of the more constrained US Core IG. Overall, this change will provide industry with more flexibility to meet Program requirements as standards evolve. We have finalized our proposal in § 170.404(b)(2) to require Certified API Developers to publish these standardized details by December 31, 2024, as proposed. We clarify that for the time period between when this final rule is effective and December 31, 2024, that Certified API Developers may fulfill their obligations at § 170.404(b)(2) by publicly publishing the service base URLs for all customers in a machine-readable format at no charge.</P>
                    <P>
                        This modification supports our goal of addressing the inconsistent implementation of our service base URL requirement and better facilitates 
                        <PRTPAGE P="1288"/>
                        patient access to their health information by requiring the use of a consistent data format, while also reflecting feedback received from software developers, technology companies, and standards developer interested parties. This modification also better aligns our requirements with the underlying data format constructs currently defined in the leading, and still emerging, industry specification in this area, namely the Patient-access Brands specification. We hope to give Certified API Developers the option of using the data format structure in Patient-access Brands specification to publish their service base URLs and organization data we require without being in conflict with our data format requirements for the Program. We note that at the time of publication of this final rule, the Patient-access Brands specification is still in draft form and may evolve over time, including the addition of breaking changes. We will consider the Patient-access Brands specification for adoption in future rulemaking as it develops.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         In addition to the Patient-access Brands specification, several commenters noted the Directory IG for TEFCA as a standard to consider for the endpoint publication use case. All but one of these commenters cited the Directory IG for TEFCA alongside the Patient-access Brands specification and advocated for the alignment of TEFCA with the Patient-access Brands specification. One commenter advocated specifically for changes to our proposal based on the Directory IG for TEFCA, stating that we should consider it for defining the format of FHIR “Organization” and “Endpoint” resources for the endpoint publication use case.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the notes from commenters pointing us to other work in the endpoint publication space to consider. The Directory IG for TEFCA is under active development and is being designed to support the TEFCA use case and the participants within that framework. 
                        <SU>171</SU>
                        <FTREF/>
                         We agree that this IG is an important standard to keep in mind for supporting the endpoint publication use case more broadly but, because it already includes constraints and extensions that go beyond the relatively small set of elements we proposed requiring of developers, we do not agree with the commenter who suggested using it for specifying the format of FHIR “Organization” and “Endpoint” resources used for publishing endpoints in our Program at this time. However, we note that because we have finalized an approach in § 170.404(b)(2) that references the base FHIR standard, Certified API Developers have the flexibility to consider using “Organization” and “Endpoint” FHIR resources profiles, such as the profiles in the Directory IG for TEFCA, to meet our requirements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>171</SU>
                             
                            <E T="03">https://rce.sequoiaproject.org/RCEIG/output/index.html.</E>
                        </P>
                    </FTNT>
                    <P>Regarding the suggestions to align TEFCA with the Patient-access Brands specification, we thank commenters for this suggestion but note that it is outside the scope of the proposals related to TEFCA in the HTI-1 Proposed Rule. We will continue to monitor the development of these standards and may take them into consideration in future rulemaking.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters asked that we clarify the intended use of the organization details we proposed to be published. More specifically, commenters asked that we clarify that we expect organization or facility level identifiers, rather than individual practitioner identifiers, to be published. Many of these commenters noted that the publication of individual practitioner identifiers is out of scope for our intended use case. Additionally, one commenter noted the active work on a National Directory FHIR IG and said that it would be an approach to consider if we intend for practitioner level identifiers to be published.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' input and suggestions for clarity. We intend for these additional organization details to be used by app developers to help them map organizations to endpoints which, in turn, helps patients find the organization(s) they want to allow an app to access data from. We clarify that facility or organization level identifiers are sufficient to satisfy our proposed publication requirements. Facility level identifiers, for the purposes of certification to these Endpoint publication requirements, include identifiers such as: a National Provider Identifier (NPI), Clinical Laboratory Improvement Amendments (CLIA) number, CMS Certification Number (CCN), or other health system ID. Support for one of these identifier types is sufficient, meaning Certified API Developers are not required to publish individual NPIs as a floor for certification. Different identifiers may be used depending on the customers a Certified API Developer has. We have updated our regulatory text at § 170.404(b)(2)(ii)(B) to more clearly state that “[e]ach Organization resource must contain the organization's name, location, and facility identifier.”
                    </P>
                    <P>For clarity and consistency, we have also updated our regulatory text at § 170.404(b)(2), and the relevant preamble text in this final rule, to replace the word “organizational” with “organization.” The phrase “organization details” more accurately represents the details we are referring to and is a consistent phrase to use in lieu of our mixed use of “organizational” and “organization” in the HTI-1 Proposed Rule.</P>
                    <P>Regarding the comment on the active work on a National Directory FHIR IG, we thank this commenter for pointing this out. Because we have not required the publication of individual provider-level identifiers, we are not considering this IG for the endpoint publication use case in our Program. We emphasize again that because we have finalized an approach in § 170.404(b)(2) that references the base FHIR standard, Certified API Developers have the flexibility to consider using “Organization” and “Endpoint” FHIR resources profiles, such as the profiles in the National Directory FHIR IG, to meet those requirements.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A couple of commenters asked that we clarify our requirements for elements in the Endpoint and Organization FHIR resources if we are updating to US Core version 6.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters and we note that, given the changes we have made to § 170.404(b)(2)(ii) (see response to comments above), US Core is no longer in scope. We have modified the standard referenced in § 170.404(b)(2)(ii) to require the use of the base FHIR “Organization” resource instead of a US Core-profiled “Organization” resource.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters responded to our invitation for comment on whether we should finalize our proposal to adopt a requirement for FHIR Endpoint and Organization resources to be made publicly available according to the FHIR Bundle format or if we should finalize the requirement to use a ndjson format. These commenters were generally split on which format they prefer. One commenter noted that large FHIR Bundles are challenging to parse. Another commenter suggested that we align with a format that is most compatible with Lantern to support certification.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these responses and suggestions from commenters. We have finalized, at § 170.404(b)(2)(iii)(A), our requirement for FHIR Endpoint and Organization resources to be collected in FHIR Bundle resource format. We recognize that large FHIR Bundles may be hard to parse given their size, but we anticipate that app developers will have the technology and access to the tools 
                        <PRTPAGE P="1289"/>
                        needed to parse large machine-readable artifacts. We also note that the current draft Patient-access Brands specification calls for the use of FHIR Bundles to collect FHIR Endpoint and Organization details.
                        <SU>172</SU>
                        <FTREF/>
                         We believe that our finalized requirement for publication using the FHIR Bundle resource format sufficiently supports app developers and aligns with industry direction.
                    </P>
                    <FTNT>
                        <P>
                            <SU>172</SU>
                             
                            <E T="03">https://build.fhir.org/ig/HL7/smart-app-launch/branches/pab/brands.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        We thank commenters for supporting Lantern, which is an open-source tool developed by ONC and the MITRE corporation “that monitors and provides analytics about the availability and adoption of FHIR API service base URLs (endpoints) across healthcare organizations in the United States.” 
                        <SU>173</SU>
                        <FTREF/>
                         We anticipate that Lantern and other FHIR tools will be able to take advantage of our standards-based and machine-readable approach to monitor and discover FHIR endpoints. We also note that the Program will continue to explore ways to support conformance and certification to these requirements to enable patients and other users to access, exchange, and use information via discoverable FHIR APIs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>173</SU>
                             
                            <E T="03">https://lantern.healthit.gov/?tab=dashboard_tab.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested that both human readable and machine-readable Endpoint metadata be made available on the CHPL.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank this commenter for their suggestion. We acknowledge that human readable Endpoint metadata may be useful for some use cases, but we do not believe that is a necessary additional requirement to put on Certified API Developers in our Program. We note that by requiring machine-readable publication using a standardized FHIR format, developers can consider developing their own tools or leveraging existing community tools (
                        <E T="03">e.g.,</E>
                         Lantern) that render FHIR data into human readable formats.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter explicitly expressed support for the quarterly review timeline we proposed for Certified API Developers in § 170.404(b)(2)(iii)(B), while two commenters recommended changes to the timeline. The two commenters who recommended changes indicated that a quarterly review minimum was too long given that inaccurate organization details and non-functioning endpoints significantly hinders interoperability. One of these two commenters suggested the review timeline be one week and the other suggested that ONC notify organizations of any inaccurate information after 30 days and find them in violation if no corrective updates are made after 60 days.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback and thoughtful suggestions for possible improvement from commenters. We agree that this information needs to remain up to date to ensure application developers can easily and consistently provide patients access to EHI. We also acknowledge the need to consider the burden on Certified API Developers to keep their customers' endpoint information up to date. To balance value and burden, we have finalized the review timeline as proposed and have finalized a quarterly review timeline as the requirement. In response to commenters' suggestion that ONC monitor and notify interested parties of inaccurate information and initiate corrective action after 60 days, we note that we have a defined process to elevate concerns of non-conformity and we urge users or other interested parties to leverage this process.
                        <SU>174</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>174</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/certified-health-it-complaint-process.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters suggested that ONC work on a process for validating and monitoring these endpoints. Many of these commenters also suggested that we develop a directory of these endpoints. One commenter specifically cited our Lantern tool as a central place where these endpoints could be submitted and validated.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their feedback and suggestions. All Certified API Developer published Endpoint and Organization FHIR resource Bundles will be available publicly via the CHPL. Links to these Bundles are collected during the certification process by the ONC-Authorized Certification Bodies (ONC-ACB) and posted on a product's CHPL listing following successful certification. This public data can be used by anyone for collection and monitoring. This includes ONC's open-source Lantern tool. ONC hosts a public instance of this tool at 
                        <E T="03">https://lantern.healthit.gov/</E>
                         and collects data into this instance from many sources, including the CHPL, to monitor and provide analytics about the availability and adoption of FHIR API endpoints.
                        <SU>175</SU>
                        <FTREF/>
                         We encourage interested parties to visit the Lantern tool and we will continue to consider ways to ensure that service base URLs required in the Program continue to support individuals' access to their health information.
                    </P>
                    <FTNT>
                        <P>
                            <SU>175</SU>
                             
                            <E T="03">https://lantern.healthit.gov/?tab=about_tab.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters expressed concern over the burdens and challenges for EHR developers to collect this information from their customers and be responsible for it being up to date. This included comments that Certified API Developers should not be penalized if and when their customers do not provide this information. One commenter asked that ONC clarify that Certified API Developers can rely on assurances provided by their customers that this information is valid and up to date, because it will not be feasible for developers to independently validate the information, and that Certified API Developers should instead only be expected to publish information for customers that provide details to the Certified API Developers, rather than an expectation that endpoint and organization detail lists are comprehensive. A couple of commenters suggested the introduction of a CMS attestation for providers and hospitals to be responsible for this information and keeping it up to date.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters and acknowledge these concerns from Certified API Developers about gathering endpoint and organization information from their customers and being responsible for its publication. However, we did not propose and have not finalized any changes to our existing policy at § 170.404(b)(2) that requires Certified API Developers to publicly publish the service base URLs for all of their customers regardless of whether the Health IT Modules certified to § 170.315(g)(10) are centrally managed by the Certified API Developer or locally deployed by an API Information Source. As we said in the ONC Cures Act Final Rule with regards to publication of service base URLs, we believe that Certified API Developers will have adequate relationships with API Information Sources in the process of providing Health IT Modules certified to § 170.315(g)(10) to gather the necessary information (85 FR 25765). We believe that these same relationships are adequate for Certified API Developers to be able to collect and publish service base URLs, organization names, organization locations, and facility identifiers on behalf of their customers. We do not agree that it will be infeasible for Certified API Developers to provide validated URLs for customers that locally deploy certified API technology because details related to customer names, organization locations, and facility identifiers should be routinely and readily available during the business process (
                        <E T="03">i.e.,</E>
                         a Certified API Developer licensing or selling use of certified API technology to a customer). We remind commenters of our focus for 
                        <PRTPAGE P="1290"/>
                        this criterion on service base URLs and related organization details for Health IT Modules certified to § 170.315(g)(10) that can be used by patients to access their EHI. We believe that the effort needed to collect this information is warranted given the critical role it plays in enabling third-party apps to access EHI at a patient's request.
                    </P>
                    <P>We appreciate the feedback and suggestions from commenters on potential points of intersection between our requirements and CMS requirements. Updates to CMS programs are out of scope of this rule, but we encourage commenters to submit such ideas to CMS.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters suggested that we work with CMS and other federal partners to ensure our requirements do not duplicate other efforts and to ensure that the necessary infrastructure is in place to support this requirement. One commenter specifically cited CMS's ongoing effort to develop a national directory.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. We will continue to coordinate and work with our federal partners, including CMS, on points of intersection for potential future rulemaking.
                    </P>
                    <HD SOURCE="HD3">d. Access Token Revocation</HD>
                    <P>In the ONC Cures Act Final Rule, we established a requirement in § 170.315(g)(10)(vi) that for Health IT Modules certified to § 170.315(g)(10), the Health IT Module's authorization server must be able to revoke an authorized application's access at a patient's direction (85 FR 25945). This required capability is intended to enable patients to “definitively revoke an application's authorization to receive their EHI until reauthorized, if ever, by the patient” (85 FR 25747). We noted in the ONC Cures Act Final Rule that we finalized § 170.315(g)(10)(vi) as a functional requirement to allow health IT developers the ability to implement it in a way that best suits their existing infrastructure and allows for innovative models for authorization revocation to develop (85 FR 25747). We understand that a lack of specificity in the current requirement has led to some confusion among health IT developers and application developers.</P>
                    <P>As part of health IT developers' implementation of these requirements, we have received feedback regarding the implementation of authorization revocation, specifically around the revocation of access tokens. Health IT developers have requested clarification regarding letting access tokens expire in lieu of immediate access token revocation for the purposes of certification testing. The Oauth 2.0 Token Revocation specification, RFC 7009, describes expiration of short-lived access tokens as a design option for authorization servers to revoke an application's access. This design option conforms with industry standard practice and may reduce health IT developer burden as the Health IT Module would not have to perform token introspection for each resource request nor maintain a database of valid access tokens.</P>
                    <P>
                        In the HTI-1 Proposed Rule, we proposed to revise the requirement in § 170.315(g)(10)(vi) to specify that a Health IT Module's authorization server must be able to revoke and must revoke an authorized application's access at a patient's direction within 1 hour of the request (88 FR 23816). This requirement aligns with industry standard practice of short-lived access tokens as specified in internet Engineering Task Force (IETF) Request for Comments (RFC) 6819,
                        <SU>176</SU>
                        <FTREF/>
                         IETF RFC 7009,
                        <SU>177</SU>
                        <FTREF/>
                         and Section 7.1.3 of the SMART Application Launch Framework version 1.0.0, which states that “Access tokens SHOULD have a valid lifetime no greater than one hour. Confidential clients may be issued longer-lived tokens than public clients.” This policy would provide clarity and create a consistent expectation that developers revoke access within 1 hour of a request, regardless of their internal approach to fulfilling a patient's request to revoke access. This policy would also assure patients that once requested, an application's access to their data would be revoked within 1 hour. This would also support situations where a patient may have an unexpected change in their privacy concerns and seek to curtail access to their information.
                    </P>
                    <FTNT>
                        <P>
                            <SU>176</SU>
                             Available at: 
                            <E T="03">https://www.rfc-editor.org/pdfrfc/rfc6819.txt.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>177</SU>
                             Available at: 
                            <E T="03">https://www.rfc-editor.org/pdfrfc/rfc7009.txt.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters supported our proposal to revise § 170.315(g)(10)(vi) to specify that a Health IT Module's authorization server must be able to revoke and must revoke an authorized application's access at a patient's direction within 1 hour of the request. Several commenters, including health IT companies, medical software companies, professional trade associations, some healthcare systems, and consumer/patient advocacy groups agreed with our rationale that such a requirement supported patients' direct control over the applications that have access to their EHI, and that the requirement is consistent with industry standards.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. We believe our proposal would assure patients that once requested, an application's access to their data would be revoked within 1 hour and that such revocation could be supported by all Health IT Modules regardless of their internal approach to fulfilling a patient's request to revoke access. We appreciate the overall strong support for our proposal that, for Health IT Modules certified to § 170.315(g)(10), the Health IT Module's authorization server must be able to revoke and must revoke an authorized application's access at a patient's direction within 1 hour of the request. We have adopted our proposal in § 170.315(g)(10)(vi) without revisions.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A small number of commenters opposed our proposal, for differing reasons. A healthcare system and a medical software company commented that 1 hour is too long a period of time to execute a revocation request, and a trade organization said 1 hour was too short. Two commenters worried about implications related to information blocking, including a professional trade association that said that providers should be able to request that an app developer delete any data received through the API between when the request was made and when access had been revoked without trigging information blocking concerns, and a medical software company worried about information blocking claims if revocation within 1 hour was not feasible due to technical challenges, such as a network outage at a cloud provider.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these commenters' concerns. However, we note that this proposed requirement aligns with industry standard practice of short-lived access tokens as specified in IETF RFCs 6819 and 7009. We also note that this 1-hour requirement does not preclude a Health IT Module from revoking access in a shorter timeframe; rather, it establishes a maximum timeframe for the revocation of access once requested. Based on community feedback, we respectfully disagree with the commenter indicating that 1 hour is not enough time to process such a request; industry consensus, as discussed above with the IETF RFCs, and experience with implementing the Program requirement to-date, indicates that many, if not most, requests can be easily fulfilled within 1 hour. We have established this timeframe to clearly delineate Program expectations, which did not previously exist. Finally, we appreciate commenters' concerns regarding information blocking; however, we currently do not provide 
                        <PRTPAGE P="1291"/>
                        an exception specific to access token revocation and we decline to do so at this time. We also invite readers to review the discussion regarding the Infeasibility Exception, finalized by the ONC Cures Act Final Rule in § 171.204 (85 FR 25866-25875), and our discussion of the Infeasibility Exception and its 
                        <E T="03">responding to requests</E>
                         condition (§ 171.204(b)) discussed in section IV.C.1 of this final rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter from a health system recommends that the ONC liaise with the Federal Trade Commission (FTC) to consider introducing a requirement such that, when consumer apps that access, exchange, or use personal health records experience a breach and are required to notify users of such a breach, those apps also include easy-to-understand instructions about how to revoke access to that application via certified health IT products and the timeframe in which such revocation must occur.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment and will continue to coordinate and work with our federal partners, including the FTC, on points of intersection for potential future rulemaking.
                    </P>
                    <P>We appreciate the overall strong support for our proposal that a Health IT Module's authorization server must be able to revoke and must revoke an authorized application's access at a patient's direction within 1 hour of the request and we have adopted our proposal in § 170.315(g)(10)(vi) without revisions.</P>
                    <HD SOURCE="HD3">e. SMART App Launch 2.0</HD>
                    <P>In the ONC Cures Act Final Rule, we adopted the HL7 FHIR SMART Application Launch Framework Implementation Guide Release 1.0.0 (SMART v1 Guide), a profile of the Oauth 2.0 specification, in § 170.215(a)(3) (85 FR 25741). The SMART v1 Guide provides reliable, secure authorization for a variety of app architectures through the use of the Oauth 2.0 standard. This IG defines various capabilities for app support, known as the “SMART on FHIR Core Capabilities” (85 FR 25741). As part of adopting the implementation specification in § 170.215(a)(3), the ONC Cures Act Final Rule required support for these “SMART Core Capabilities,” which enable applications to securely perform standardized authentication and authorization as part of enabling receipt of patient EHI via a FHIR API.</P>
                    <P>In the ONC Cures Act Final Rule, the § 170.315(g)(10) “Standardized API for patient and population services” certification criterion required support for capabilities from the SMART v1 Guide as described in § 170.215(a)(3) to enable apps to securely perform authentication and authorization with the Health IT Module in a standardized manner. Additionally, the § 170.315(g)(10) criterion included additional requirements for technical capabilities specified in the SMART v1 Guide, requiring support for the issuance of “refresh tokens” valid for a period of no less than three months. This requirement was intended to reduce patient and provider burden to receive patient EHI using an application of their choice by potentially reducing the number of re-authorizations of the application. Support for refresh tokens facilitates patient and provider receipt of patient EHI by enabling an application to be authorized to receive data in a persistent manner, without requiring re-authorization of the application while the refresh token is valid. The § 170.315(g)(10) criterion required support for the issuance of refresh tokens valid for a period of no less than three months, so that an application could potentially be authorized to receive patient EHI for at least a three-month period without requiring re-authorization.</P>
                    <P>
                        As part of the adopted implementation specification, we explicitly required mandatory support of the “SMART Core Capabilities” for Program testing and certification, and we stated that by requiring the “permission-patient” “SMART Core Capability” in § 170.215(a)(3), Health IT Modules presented for testing and certification to § 170.315(g)(10), via cross-references to § 170.215(a)(3), must include the ability for patients to authorize an application to receive their electronic health information (EHI) based on FHIR resource-level scopes (85 FR 25741, 25746). Practically, this means that patients would need to have the ability to authorize access to their EHI at the individual FHIR resource-level, from one specific FHIR resource (
                        <E T="03">e.g.,</E>
                         “Immunization”) up to all FHIR resources necessary to implement the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2). This capability gives patients increased control over how much EHI they authorize applications of their choice to receive.
                    </P>
                    <P>
                        The SMART App Launch Implementation Guide Release 2.0.0 (SMART v2 Guide) is the next major release of the SMART App Launch IG.
                        <SU>178</SU>
                        <FTREF/>
                         The SMART v2 Guide updates the features of the SMART v1 Guide by including revisions aligning with industry consensus to provide technical improvements and reflect security best practices. The SMART v2 Guide technical enhancements improve the authentication and authorization security layer provided by the SMART v1 Guide and enables increased capabilities and functionality for individual control of EHI. Therefore, we proposed to adopt the SMART v2 Guide in § 170.215(c)(2), and we proposed that the adoption of the SMART v1 Guide in § 170.215(c)(1) would expire as of January 1, 2025 (88 FR 23816). We clarified that both the SMART v1 Guide and SMART v2 Guide will be available for purposes of certification where certification criteria reference § 170.215(c) until the expiration date of January 1, 2025, after which time only the SMART v2 Guide will be available for certification.
                    </P>
                    <FTNT>
                        <P>
                            <SU>178</SU>
                             
                            <E T="03">https://hl7.org/fhir/smart-app-launch/STU2/index.html.</E>
                        </P>
                    </FTNT>
                    <P>As part of this proposal, we proposed to adopt several sections specified as “optional” in the SMART v2 Guide as “required” for purposes of the Program for certification criteria that reference § 170.215(c). Specifically, we proposed to adopt all Capabilities as defined in “8.1.2 Capabilities,” which include but are not limited to (1) backward compatibility mapping for SMART v1 scopes as defined in “3.0.2 Scopes for requesting clinical data;” (2) asymmetric client authentication as defined in “5 Client Authentication: Asymmetric (public key);” and granular scopes as defined in (3) “3.0.2.3 Finer-grained resource constraints using search parameters.” Additionally, we proposed to require support for the “Patient Access for Standalone Apps” and “Clinician Access for EHR Launch” Capability Sets from “8.1.1 Capability Sets.” Also, we proposed to adopt token introspection as defined in “7 Token Introspection.” Again, we clarified that for the period before January 1, 2025, Health IT Modules certified to certification criteria that reference § 170.215(c) may use either SMART v1 or SMART v2 for certification (88 FR 23817).</P>
                    <P>
                        Further, we noted that the SMART v2 Guide includes section 3.0.2.3 “Finer-grained resource constraints using search parameters,” and associated “3.0.2.4 requirement for support” and “3.0.2.5 experimental features,” which present concepts for further development within the SMART v2 Guide (88 FR 23817). Together, these optional functionalities will enable more granular control for individuals, clinicians, and other users to share information with apps of their choice in more explicit ways. The granular scope functionality would empower patients and providers to share health data in a 
                        <PRTPAGE P="1292"/>
                        more granular fashion, which would improve confidence in the use of third-party apps by allowing app users to decide which specific type of EHI they share with the app. These functionalities would help address privacy and security concerns of third-party app access to health data and further patient empowerment by providing the ability to limit an app's access to a granular, minimum set of health data, as determined by the app user. We proposed these sections for adoption as part of SMART v2 Guide with the understanding that either the SMART v2 Guide or another implementation guide such as the US Core Implementation Guide will define more specific requirements for finer-grained resource constraints using search parameters.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         There was near universal support for adoption of the SMART v2 Guide among commenters, including health IT companies, software and IT firms, advocacy organizations, and health systems. Several commenters noted that the SMART v2 Guide would play a crucial role in promoting health data interoperability and facilitating seamless data exchange between healthcare systems and applications. However, there was strong support among many of these interested parties to adopt the newest balloted version of the SMART App Launch Implementation Guide, Release 2.1. (SMART v2.1 Guide), rather than the SMART v2 Guide. Several commenters highlighted the benefits of the SMART v2.1 Guide, including improved FHIR Context management and App State capability. Some commenters also recommended ONC require support for browser-based apps, including requirements from the SMART v2.1 Guide.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their support. We have finalized the adoption of the SMART v2 Guide subject to modifications described later in this section. We believe that adoption of the SMART v2 Guide will enable an improved and more secure authorization process for applications to receive EHI from Health IT Modules. We appreciate commenters' input regarding adoption of the subsequent release of the SMART v2.1 Guide. We acknowledge there are noteworthy updates included in the SMART v2.1 Guide. However, given that the SMART v2 Guide has already been an established part of the Program via SVAP and rigorously tested as a result, we believe adopting the SMART v2 Guide as a baseline requirement is more appropriate at this time. We will consider potential ways the SMART v2.1 Guide could be included in the Program in the future, including through SVAP. We also clarify that browser-based apps fitting the definition of “public clients”, or “native applications” as defined in internet Engineering Task Force Request for Comments 6749 (RFC 6749), are required to be supported by Health IT Modules certified to the § 170.315(g)(10) criterion, per the requirements of that criterion. Such relevant requirements for supporting “public clients” and “native applications” include the data response, search, registration, secure connection, authentication and authorization for patient and user scopes, and authorization revocation requirements in the § 170.315(g)(10) criterion, respectively at § 170.315(g)(10)(i)(A), § 170.315(g)(10)(ii)(A), § 170.315(g)(10)(iii), § 170.315(g)(10)(iv)(A), § 170.315(g)(10)(v)(A), and § 170.315(g)(10)(vi).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters were mixed in their recommendations on our proposal to expire the use of the SMART v1 Guide as part of the Program on January 1, 2025, effectively requiring use of only the SMART v2 Guide for applicable certification criteria after that date. Among those interested parties that commented, professional associations urged ONC to finalize the timeline as proposed. Health information technology companies and one health system requested additional time, indicating that the proposed expiration timeframe of January 1, 2025, does not give organizations sufficient time to develop, test, and implement necessary changes to systems and processes.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their input. We acknowledge the benefits of extending the timeframe in which the SMART v1 Guide is available for certification. Taking this into consideration, we have modified our proposal as suggested by commenters who recommended more time to adopt only the SMART v2 Guide. We have, therefore, finalized our modified proposal that the adoption of the SMART v1 Guide implementation specification expires on January 1, 2026, and we clarify that following expiration of the SMART v1 Guide, the SMART v2 Guide will be the only valid standard for certification criteria that reference § 170.215(c).
                    </P>
                    <HD SOURCE="HD3">i. SMART v2 Guide New and Revised Features Proposed for Adoption</HD>
                    <P>
                        The SMART v2 Guide introduces new or revised requirements to the previous version of the implementation guide, SMART v1 Guide. Major requirements new to the SMART v2 Guide include support for the OAuth 2.0 security extension Proof Key for Code Exchange (PKCE), as well as a revision of the scope syntax. The SMART v2 Guide includes requirements that both the EHR and all apps support the OAuth 2.0 security extension PKCE. PKCE is an industry standard security extension for OAuth 2.0 to mitigate the known security vulnerability of authorization code interception attacks.
                        <SU>179</SU>
                        <FTREF/>
                         The requirement of support for PKCE especially improves the security of native apps, or apps that operate from an individual's phone or tablet, which were particularly vulnerable to authorization code interception attacks.
                    </P>
                    <FTNT>
                        <P>
                            <SU>179</SU>
                             
                            <E T="03">https://www.oauth.com/oauth2-servers/pkce/.</E>
                        </P>
                    </FTNT>
                    <P>Another major change included in the SMART v2 Guide is revision of the syntax of scopes provided to apps. To align with the FHIR interactions of “Create,” “Read,” “Update,” “Delete,” “Search,” collectively known as “CRUDS,” scopes are constructed to consist of combinations of five types of permissions corresponding to the CRUDS interactions. The use of this CRUDS scope syntax permits improved patient choice for persistent access as more specific combinations of permissions can be granted to apps as opposed to the scope syntax used in the SMART v1 Guide, which only used two permission types of “read” and “write.”</P>
                    <P>
                        <E T="03">New feature: PKCE</E>
                    </P>
                    <P>
                        One of the major security improvements in the SMART v2 Guide is the requirement that all apps support the OAuth 2.0 security extension Proof Key for Code Exchange (PKCE). PKCE is designed to mitigate the known security vulnerability of authorization code interception attacks, with native apps especially targeted. According to IETF RFC 7636,
                        <SU>180</SU>
                        <FTREF/>
                         the request for comment which defines the PKCE extension, this attack can be used to illegitimately obtain an access token from the authorization server and thus obtain server data in an unauthorized manner. PKCE mitigates this vulnerability by creating cryptographically random keys for every authorization request. The authorization server performs proof of possession of the secret key by the client. This mitigates the vulnerability as an attacker who intercepts the authorization code cannot redeem it for an access token as they do not possess the secret key associated with the authorization request.
                    </P>
                    <FTNT>
                        <P>
                            <SU>180</SU>
                             See IETF RFC 7636 at: 
                            <E T="03">https://www.rfc-editor.org/rfc/rfc7636.</E>
                        </P>
                    </FTNT>
                    <P>
                        Support for PKCE is important because PKCE makes health app access 
                        <PRTPAGE P="1293"/>
                        of patient health information more secure in a standardized manner. ONC recognizes healthcare participants and patients are interested in the secure use of health apps, including native apps, to access health information. PKCE support makes the granting of access to health information via health apps more secure by mitigating the known vulnerability of authorization code interception attacks. We believe the support of PKCE would further our goal of secure access of health information without special effort by further securing health app access, especially for native apps. Therefore, we proposed to require the support of PKCE as specified in the SMART v2 Guide (88 FR 23817).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         All comments received from interested parties supported adoption of the OAuth 2.0 security extension PKCE in the SMART v2 Guide. Many commenters noted that adoption and required support for PKCE is aligned with industry best practice and forthcoming updates to OAuth in draft version 2.1.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their support. We believe the support of PKCE would further our goal of secure access of health information without special effort by further securing health app access, especially for native apps. Therefore, we have finalized adoption of the SMART v2 guide with inclusion of PKCE. This means that Health IT Modules presented for testing and certification to § 70.315(g)(10) must support PKCE.
                    </P>
                    <P>
                        <E T="03">New Feature: CRUDS scope syntax</E>
                    </P>
                    <P>Another major update in the SMART v2 Guide is the revision of the scope syntax to align with the FHIR REST API interactions for FHIR resources. Previously in the SMART v1 Guide, scope syntax for FHIR resources was delineated in terms of combinations of “read” and “write” permissions. The SMART v2 Guide revises this scope syntax by splitting “read” permissions into two types of permissions which correspond to FHIR REST API interactions, “Read” and “Search.” Similarly, the “write” permissions from the SMART v1 Guide are split into “Create,” “Update,” and “Delete.” This alignment of scope syntax to the FHIR REST API interactions permits Health IT Module authorization servers to provide greater specificity regarding which permissions are granted in scopes to apps and has the benefit of improved technical clarity to health IT and application developers. This additional specificity for scopes also improves a patient's control over how an app accesses their health data by clarifying for the patient what specific type of API interactions are permitted to the app. For example, under this new syntax the patient could specifically permit an app “read” access to a FHIR resource but deny “search” access for the same FHIR resource.</P>
                    <P>As stated in the ONC Cures Act Final Rule at 85 FR 25742, the § 170.315(g)(10) certification criterion only requires health IT developers to support “read” capabilities according to the standard and implementation specifications adopted in § 170.215(a) and in § 170.215(b)(1), including the mandatory capabilities described in “US Core Server Capability Statement.” Our proposal aligns with this existing policy for § 170.315(g)(10) by proposing to require that only “Read” and “Search” permissions as specified in the SMART v2 Guide be supported for certification to the § 170.315(g)(10) criterion.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Comments from health IT companies supported our proposals to adopt the SMART v2 revised scope syntax of “Create,” “Read,” “Update,” “Delete,” and “Search,” or CRUDS. They noted that the new syntax supports flexible and patient-friendly user interfaces (UI). One commenter noted that ONC should maintain current policy allowing developers the flexibility to present authorization scopes in a more user-friendly format, such as by logically grouping FHIR resource-level scopes, as long as users are able to grant FHIR resource-level scope authorizations, if requested. We also received a comment recommending against requiring support for wildcard scopes as defined in the SMART v2 Guide due to concerns about data management and security in patient access use cases.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their support and comments. In consideration of the comments received, we have finalized as proposed the requirement for Health IT Modules certified to § 170.315(g)(10) to support the SMART v2 scope syntax for the “Read” and “Search” permissions as specified in the SMART v2 Guide. We clarify that Health IT Modules supporting the SMART v2 Guide scope syntax and the “permission-patient” capability from the SMART v2 Guide are not required to support wildcard scopes relating to authorization to receive a single patient's data. Instead, we align with the policy as mentioned in the ONC Cures Act Final Rule (85 FR 25741) that as part of supporting the “permission-patient” capability, Health IT Modules presented for testing and certification must include the ability for patients to authorize an application to receive their EHI based on FHIR resource-level scopes.
                    </P>
                    <HD SOURCE="HD3">ii. SMART v2 Optional Features Proposed as Required by ONC</HD>
                    <P>We proposed to require all Capabilities as defined in “8.1.2 Capabilities” and the “Patient Access for Standalone Apps” and “Clinician Access for EHR Launch” Capability Sets from “8.1.1 Capability Sets” (88 FR 23817 through 23819). First, the SMART v2 Guide introduces functionality specified as optional in the implementation guide. We proposed to make several of these optional functionalities required as part of the proposed implementation specification, and therefore required for certification criteria that reference proposed § 170.215(c)(2) (88 FR 23818).</P>
                    <P>Second, the SMART v2 Guide introduces an optional profile for authorization servers to support asymmetric client authentication for confidential clients. We proposed to require Health IT Modules support asymmetric client authentication as an option for confidential clients during the process of authentication and authorization when granting access to patient data.</P>
                    <P>Third, the SMART v2 Guide also introduces a new optional feature of granular scope constraints using search parameters. This feature uses the FHIR REST API search parameter syntax to specify permissions more granular than the FHIR resource level, which was the maximum granularity of scopes in the SMART v1 Guide. We proposed to require “3.0.2.3 Finer-grained resource constraints using search parameters” with the clarification that Health IT Modules certified to § 170.315(g)(10) must minimally be capable of handling finer-grained scopes using the “category” parameter for (1) the Condition resource with Condition sub-resources Encounter Diagnosis, Problem List, and Health Concern and (2) the Observation resource with Observation sub-resources Clinical Test, Laboratory, Social History, SDOH, Survey, and Vital Signs. We note that the requirements denoted in “3.0.2.3 Finer-grained resource constraints using search parameters” would be required as part of implementing the “permission-v2” capability defined in “8.1.2 Capabilities”. We anticipated that the US Core IG would provide guidance for developers to support a minimum number of search parameters, and this minimum list would be consistent with the optional scopes described in section “3.8 Future of US Core” of the US Core IG v6.1.0.</P>
                    <P>
                        Fourth, the SMART v2 Guide revises how capabilities are categorized. The “SMART Core Capabilities” in the 
                        <PRTPAGE P="1294"/>
                        SMART v1 Guide define capabilities supported by the server and are made available to inform clients of supported functionality. “Capabilities” are grouped into “Capability Sets” to define the functionalities required for a specific use case. The SMART v2 Guide restructures how “Capabilities” are organized, and no longer includes “SMART Core Capabilities.” Instead, the SMART v2 Guide includes a list of “Capabilities” and “Capability Sets.”
                    </P>
                    <P>
                        Finally, the SMART v2 Guide introduces a new requirement to support POST-based authorization for the client authorization request. This new requirement in the SMART v2 Guide is adapted from the OpenID Connect Core specification and is related to the requirement in § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ), which requires a Health IT Module to support authentication and authorization during the process of granting access to patient data according to the SMART App Launch and OpenID Connect Core standards. The SMART v2 Guide includes the “authorize-post” capability under “Capabilities” for servers to indicate support for this requirement. To align with this new technical requirement in the SMART v2 Guide and the authorization and authentication requirement in § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ), we proposed to require the “authorize-post” capability (88 FR 23819).
                    </P>
                    <P>
                        <E T="03">Comment.</E>
                         Overall, commenters were supportive of ONC's proposals to adopt optional features in the SMART v2 Guide as required for the Program. Several commenters supported adoption of all optional features; several others supported adoption of all optional features except for “authorize-post” capability (also referred to as HTTP POST by commenters); and a minority of commenters also commented against including the “permission-online” capability. There was a comment recommending revision to the language of the token introspection proposal in § &amp;170.315(g)(10)(vii), since the SMART v1 Guide does not include a guidance section regarding token introspection. We also received a comment requesting clarity regarding requirements to independently support SMART v2 scopes separately from SMART v1 scopes.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their support and comments. We believe requiring the proposed optional features will improve the capability of applications to be authorized by users to securely receive EHI. We clarify the “authorize-post” capability is not an optional capability and is required as per the SMART v2 Guide as a method to obtain an authorization code from the authorization server. To align with the requirement as per the implementation guide, we have finalized the proposal to require the “authorize-post” capability. We encourage interested parties to participate in the development of the SMART App Launch IG if there are enhancements or technological advances regarding this capability. We proposed to require the “permission-online” capability, as part of our proposal to require all “Capabilities” as defined in “8.1.2 Capabilities,” which would enable an application to receive authorization to receive EHI while the user is logged in. In consideration of comments we received, we believe additional clarity is necessary regarding the specific authorization contexts in which this capability would be required. Also, further insight is needed regarding the use cases in which this capability provides utility beyond the “permission-offline” capability included in the proposal. Therefore, we are modifying our proposal to exclude the “permission-online” capability from the requirements of § 170.215(c)(2). Thus, we have finalized our proposal to require all Capabilities as defined in “8.1.2 Capabilities” and the “Patient Access for Standalone Apps” and “Clinician Access for EHR Launch” Capability Sets from “8.1.1 Capability Sets” of the SMART v2 Guide, except for the “permission-online” capability. We also note that since we have finalized our proposal to expire use of the SMART v1 Guide as part of the Program on January 1, 2026, that after that date certification to § 170.315(g)(10) would effectively require that token introspection be supported as described in the SMART v2 Guide. Additionally, regarding independently supporting SMART v2 and SMART v1 scopes, we note that this proposal requires the “permission-v1” and “permission-v2” capabilities as defined in the SMART v2 Guide, which define how such scopes must be supported. We clarify that the SMART v2 Guide scopes must be supported independently of the SMART v1 Guide scopes as per the “permission-v2” capability in the SMART v2 Guide, and that the SMART v1 Guide scopes must be supported as per the “permission-v1” capability in the SMART v2 Guide. Support for scopes in this manner enables the updated SMART v2 Guide scope syntax to be used by applications while also maintaining backwards compatibility with the SMART v1 Guide scopes for legacy applications.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received support from a majority of commenters that addressed ONC's proposals for support of the SMART v2 Guide's optional capability “3.0.2.3 Finer-grained resource constraints using search parameters,” including our proposal to use the “category” parameter for (1) the Condition resource with Condition sub-resources Encounter Diagnosis, Problem List, and
                        <E T="03"/>
                         Health Concern and (2) the Observation resource with Observation sub-resources Clinical Test, Laboratory, Social History, SDOH, Survey, and Vital Signs. Multiple commenters appreciated this degree of specificity and encouraged ONC to finalize this approach without further specifying in future rulemaking; instead, many of these commenters said ONC should rely on future versions of the US Core Implementation Guide to instruct further specification of other FHIR resource constraints. One health IT company recommended that we do not align scopes requirements to “search operations,” and instead adopt authorization scopes no more granular than the “category” level for FHIR resources such as Condition, Observation, Medication Request, and Diagnostic Report.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' feedback and have finalized the requirements as proposed. We note that the finalized requirements regarding “3.0.2.3 Finer-grained resource constraints using search parameters” are required as part of implementing the “permission-v2” capability defined in “8.1.2 Capabilities”. We also note that the requirements of this proposal to support finer-grained scopes using search parameter syntax and the “category” parameter are intended to align with capabilities and guidance as included in the SMART v2 Guide and FHIR US Core 6.1.0 implementation guide. We believe that establishing minimal conformance requirements at the category level for the Condition and Observation resources using specifications and guidance from these implementation guides will both ensure that Health IT Modules are capable of supporting the finer-grained resource constraints capability without being overly prescriptive in setting expectations for how the Health IT Module implements such capabilities.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters suggested that ONC adopt capabilities and standards that were outside the scope of our proposals, including “rich authorization requests,” “push authorization requests, as defined by RFC 9126,” and anti-malware capabilities, identity threat detection and response systems, the adoption of sender-constrained tokens, and OAuth 2.0 Demonstrating Proof-of-Possession 
                        <PRTPAGE P="1295"/>
                        at the Application Layer (DPoP) specification.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their recommendations, but we note that these comments are outside the scope of our proposals. We decline to accept the recommendations to adopt these capabilities, but we encourage industry to continue highlighting potential capabilities for future consideration in the Program. We also encourage interested parties to participate in the development and refinement of standards and implementation guides such as the SMART App Launch Implementation Guide.
                    </P>
                    <HD SOURCE="HD3">8. Patient Demographics and Observations Certification Criterion in § 170.315(a)(5)</HD>
                    <P>In the 2015 Edition Final Rule (80 FR 62601), ONC required the recording, capture, and access to a patient's sex, sexual orientation, and gender identity for Health IT Modules certified to the “Demographics” certification criterion (§ 170.315(a)(5)) (80 FR 62747). This rule also defined a required set of standardized terminology to represent each of these data elements (80 FR 62618-62620). Since then, ONC has received recommendations through the Health Information Technology Advisory Committee (HITAC) and public feedback that the current terms and terminologies used to represent sex, gender identity, and sexual orientation are limited and need to be updated.</P>
                    <P>
                        Meanwhile, the healthcare industry had similarly taken note of the need for precision for ideas encompassed in terms such as “sex” and “gender” and launched the Gender Harmony Project 
                        <SU>181</SU>
                        <FTREF/>
                         to capture these concepts consistently within healthcare. The Gender Harmony Project introduced for the health IT context the concepts “Sex for Clinical Use” (SFCU), “Recorded Sex or Gender” (RSG), “Name to Use,” and “Pronouns.” The Gender Harmony Project defines Sex for Clinical Use as a category that is based on clinical observations typically associated with the designation of male and female; Name to Use provides the name that should be used when addressing or referencing the patient; Recorded Sex or Gender is the documentation of a specific instance of sex and/or gender information; and Pronouns are determined by a patient and used when referring to the patient in speech, clinical notes, and in written instructions to caregivers (
                        <E T="03">e.g.,</E>
                         she/her/hers or they/them). Sex for Clinical Use, Name to Use, Recorded Sex or Gender, and Pronouns are currently not present in the certification criteria.
                    </P>
                    <FTNT>
                        <P>
                            <SU>181</SU>
                             
                            <E T="03">https://confluence.hl7.org/display/VOC/The+Gender+Harmony+Project.</E>
                        </P>
                    </FTNT>
                    <P>We outline our proposals as discussed in the HTI-1 Proposed Rule to modify the “Demographics” certification criterion (§ 170.315(a)(5)) (88 FR 23820):</P>
                    <P>We proposed to rename § 170.315(a)(5) from “demographics” to “patient demographics and observations,” to acknowledge that the data elements being proposed are broader than demographics information, as we look to promote a more inclusive healthcare system.</P>
                    <P>We proposed to add the data elements “Sex for Clinical Use” in § 170.315(a)(5)(i)(F), “Name to Use” in § 170.315(a)(5)(i)(G), and “Pronouns” in § 170.315(a)(5)(i)(H) to the “patient demographics and observations” certification criterion (§ 170.315(a)(5)). This addition reflects concepts developed by the HL7 Gender Harmony Project and help promote inclusivity in care delivery.</P>
                    <P>We proposed to revise the terminology standards specified for “Sex” in § 170.315(a)(5)(i)(C). Prior to issuing the HTI-1 Proposed Rule, ONC received significant feedback reflecting the need to be more inclusive in the terminology representing the data element. As such, ONC proposed to revise the fixed list of terms for “Sex” in § 170.315(a)(5)(i)(C), which are represented by HL7® Value Sets for Administrative Gender and NullFlavor in § 170.207(n)(1). We proposed to ultimately replace § 170.207(n)(1) with the SNOMED CT® U.S. Edition code set proposed in § 170.207(n)(2). In order to be less disruptive to developers of certified health IT, we proposed to provide flexibility and allow recording the element using the specific codes represented in § 170.207(n)(1) for the time period up to and including December 31, 2025, to provide enough time to transition their health IT systems to SNOMED CT® U.S. Edition by January 1, 2026. By having § 170.207(n)(1) expire at the end of 2025 and adding § 170.207(n)(2) as a requirement for Health IT Modules certified to § 170.315(a)(5) beginning January 1, 2026, we proposed to enable health IT developers to specify any appropriate value from the SNOMED CT® U.S. Edition code set with the standard specified in § 170.207(n)(2). We proposed to require that Sex for Clinical Use must be coded in accordance with, at a minimum, the version of LOINC® codes specified in § 170.207(c)(1).</P>
                    <P>Additionally, we proposed to replace the terminology standards specified for Sexual Orientation in § 170.315(a)(5)(i)(D), and Gender Identity in § 170.315(a)(5)(i)I. ONC has received significant feedback reflecting the need to be more inclusive in the terminology representing each of these data elements. As such, ONC proposed to revise the fixed list of terms for Sexual Orientation in § 170.315(a)(5)(i)(D), and Gender Identity in § 170.315(a)(5)I(E), which are represented by SNOMED CT® U.S. Edition and HL7® Value Set for NullFlavor in § 170.207(o)(1) and (2), and ultimately replace it with the SNOMED CT® U.S. Edition code set specified in § 170.207(o)(3).</P>
                    <P>We further proposed to set an expiration date of January 1, 2026, for the adoption of the values sets referenced in § 170.207(o)(1) and (o)(2). This allows the use of either the value sets in § 170.207(o)(1) and (o)(2) or the standard proposed in § 170.207(o)(3) beginning on the effective date of a final rule and transitioning to allow only the use of the adopted standard in § 170.207(o)(3) after December 31, 2025. Consistent with our policies in sections III.A and III.C.11, developers of certified health IT with Health IT Modules certified to criteria that reference § 170.207(o)(1) or (o)(2) would have to update those Health IT Modules to § 170.207(o)(3) and provide them to customers by January 1, 2026.</P>
                    <P>
                        We also proposed to add Sex for Clinical Use (SFCU) as a new data element in § 170.315(a)(5)(i)(F). SFCU is a category based upon clinical observations typically associated with the designation of male and female. It &amp;ports context specificity, is derived from observable information, and is preferably directly linked to &amp;e information this element summarizes. SFCU represents a patient's sex relevant to a specific clinical setting. This is valuable when providing care for a patient whose condition or treatment is dependent on their sex as determined by observing and evaluating, for example, a patient's hormonal values, organ inventory, genetic observations, or external genital morphology. SFCU may differ from a patient's sex as recorded on a birth certificate or driver's license. We further clarified, that while there may be multiple values of SFCU tied to different events, such as requesting a laboratory test or imaging study, we proposed to require health IT developer be able to record at least one value of SFCU. Additionally, in order to align with current industry practice and to provide flexibility to health IT developers, we proposed that health IT be capable of recording SFCU using the LOINC® terminology code set standard specified in proposed § 170.207(n)(3).
                        <PRTPAGE P="1296"/>
                    </P>
                    <P>We proposed to add new data elements Name to Use in § 170.315(a)(5)(i)(G) and Pronouns in § 170.315(a)(5)(i)(H), respectively, to advance the culturally competent care for lesbian, gay, bisexual, transgender, queer, intersex, asexual, and all sexual and gender minority (LGBTQIA+) people. Multiple values for a given patient may be valid over time. We require at least one value for Pronouns and Name to Use be recorded. Additionally, in order to align with current industry practice and to provide flexibility to health IT developers, we proposed that health IT be capable of recording Pronouns using the LOINC® terminology code set standard specified in proposed § 170.207(o)(4).</P>
                    <P>In addition to the other data elements proposed, the HL7 Gender Harmony Project created an element named Recorded Sex or Gender (RSG). RSG documents a specific instance of sex and/or gender information. RSG is considered a complex data element that includes provision for a sex or gender value, as well as reference to the source document where the value was found, whereas Sex is a simple data element. RSG provides an opportunity for health IT developers to differentiate between sex or gender information that exists in a document or record, and from Sex for Clinical Use (SFCU) which is designed to be used for clinical decision-making. In the HTI-1 Proposed Rule, ONC asked commenters to evaluate two options and provide feedback regarding whether Recorded Sex or Gender as defined by the HL7 Gender Harmony Project should be incorporated into 170.315(”)(5) “patient demographics and observations” (88 FR 23820).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters did not support the proposed deadline and instead suggested a deadline of 24 months after the effective date of the final rule as this would be in line with the proposed “timeliness” provisions of the Assurances Condition and Maintenance of Certification requirements. Other commenters specifically proposed December 31, 2025, for the adoption of new and updated certification criteria.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for the comments suggesting an extension to the proposed effective dates. In assessing the overall burden and proposed timeframes, we have revised the compliance dates to allow for 24 months for compliance and finalized the adoption of § 170.315(a)(5) with a compliance date of January 1, 2026. We have also revised the “timeliness” requirement in the Assurances Condition to avoid confusion.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Most commenters supported the addition of Sex for Clinical Use, Name to Use, Sex, and Pronouns to § 170.315(a)(5) “patient demographics and observations.” Some commenters noted that comprehensive demographic data supports holistic understanding of patients' background, leading to culturally competent and patient-centered care. Commenters also encouraged ONC to continue collaborating with the HL7 Gender Harmony Project to provide more detail regarding the definitions and supporting terminologies—supporting the ability for people to provide more nuanced information about themselves to best inform care. Commenters also suggested that ONC explore how Sex for Clinical Use could be expanded to incorporate organ inventory and hormone levels. One commenter suggested that ONC promote Sex for Clinical Use as a repeatable set of observations. Another commenter suggested that the addition of Pronouns, Name to Use, and Sex for Clinical Use would create unnecessary confusion, increased medical risk, and religious conscience concerns. Other commenters expressed concern that it will be difficult to collect Sex for Clinical Use as the clinician interacting with the patient may not have the information necessary to provide a value. Some commenters expressed concern about the complexities of dealing with context-specific Sex for Clinical Use data.
                    </P>
                    <P>Some commenters expressed concern that there is not sufficient information or guidance for programs and health IT to implement Sex for Clinical Use, therefore it should not be included in § 170.315(a)(5) “patient demographics and observations.” Several commenters suggested that ONC wait to add any data elements to “patient demographics and observations” until the data elements are part of USCDI. Other commenters supported the addition of Sex for Clinical Use, Name to Use and Pronouns to the “patient demographics and observations” criterion rather than USCDI, as adding to USCDI and then SVAP would greatly slow adoption since SVAP is optional.</P>
                    <P>
                        <E T="03">Response.</E>
                         ONC thanks the commenters expressing support for Name to Use, Pronouns, and Sex for Clinical Use. Including “patient demographics and observations” criterion in this final rule provides time for Health IT Modules to incorporate support for capture of this important data prior to requiring exchange.
                    </P>
                    <P>
                        ONC collaborates closely with the HL7 Gender Harmony project team and as a result has finalized the descriptive data name change of “Sex for Clinical Use” to “Sex Parameter for Clinical Use” in § 170.315(a)(5)(i)(F). ONC will continue to support efforts to expand the scope of the HL7 Gender Harmony Project to explore how more specific information about a person's physical characteristics (
                        <E T="03">e.g.,</E>
                         organ inventory and hormone levels) can be collected and exchanged to inform Sex Parameter for Clinical Use. We have finalized as proposed (88 FR 23820) that the Health IT Module must be able to record at least one value for Sex Parameter for Clinical Use for each patient and note that there may also be multiple values tied to different events, such as requesting a laboratory test or imaging study, allowing for and encouraging more than one. We recognize that the Sex Parameter for Clinical Use data element may be a new concept to some. However, we note that developers of certified health IT have the flexibility to configure their user interface and to capture and display these data in clinical workflows consistent with their own design decisions.
                    </P>
                    <P>ONC appreciates the concerns expressed by some commenters about lack of guidance to implement Sex Parameter for Clinical Use (formerly Sex for Clinical Use); however, at the time of this final rule, HL7 has published updated specifications that provide specific exchange guidance that may then inform incorporation into health IT workflows. ONC has identified Sex Parameter for Clinical Use, Name to Use, and Pronouns as key to implementing ONC's priorities to support health equity and access for LGBTQIA+ communities. We have also finalized what was proposed to specify that at least one Name to Use and Pronouns must be recorded for each patient.</P>
                    <P>
                        With regards to the comment suggesting that collection of these data elements would create unnecessary confusion, increased medical risk, and religious conscience concerns, ONC believes that these data elements are critical to supporting healthcare, health equity, and access for LGBTQIA+ communities. Our adoption of these data elements will help to advance the capability of certified health IT to exchange these data elements for use by patients and health care providers. Our adoption of these data elements does not establish a requirement for health care providers or patients to record or disclose this information, or use these capabilities. As stated above, these data elements may be new concepts to some, and ONC encourages developers of certified health IT to work with providers to develop appropriate workflows.
                        <PRTPAGE P="1297"/>
                    </P>
                    <P>The “patient demographics and observations” criterion focuses on data capture and storage and not the exchange of this data, which is the focus of USCDI. Therefore, we did not accept the comment suggesting that ONC not include the data elements in § 170.315(a)(5) “patient demographics and observations” until they are included USCDI.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters suggested that ONC remove Sex and retain Sex for Clinical Use because Sex for Clinical Use paired with Gender Identity provides clear information to distinguish between a clinical categorization of a person's sex used for clinical decision making and a person's self-reported Gender Identity.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         ONC thanks commenters for their input suggesting that Sex be removed and Sex Parameter for Clinical Use (as we have renamed Sex for Clinical Use) be retained. However, more analysis by the health IT community is necessary to determine the impact of removing Sex. Therefore, ONC declines to remove Sex.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters did not support changing the title from patient demographics to patient demographics and observations, noting that all data described within are considered demographics. Other commenters noted that the title change is confusing as the criterion now includes statistical characteristics of human populations used to identify population segments and attributes associated with a diagnostic test or procedure.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We disagree with the stated concerns and do not believe that the certification criterion name change will be confusing to most in the healthcare ecosystem. The addition of the word “observations” signals that some of the data elements in this data class may not be statistical characteristics of human populations by all people evaluating the certification criterion. Accordingly, we have finalized the criterion title change as proposed.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Multiple commenters expressed concern about changing the requirement for specific code set concepts for Sexual Orientation and Gender Identity to a more general reference to SNOMED CT U.S. Edition. They also questioned whether health IT developers would be compliant if other values are exchanged such as “unknown” or “asked but did not answer.” Other commenters supported ONC's plans to move value set definitions out of regulatory text and delegate to industry groups. One commenter suggested referencing specific value sets defined in the Value Set Authority Center.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         ONC thanks the commenters for their input and assures them that ONC collaborates with health IT developers to develop specific values that may be exchanged, including those that indicate a standard value is not available, such as “unknown” or “asked but did not answer”. The resulting value sets may be defined in the Value Set Authority Center. Removing specific code set concepts from regulation allows health IT developers to provide options that are culturally relevant and may change on a cycle that is different from regulation.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters did not support the addition of Sex with the requirement that data values be drawn from SNOMED CT U.S. Edition. Others expressed concern that the addition of Sex may increase confusion among senders and receivers about the various data elements currently in use—administrative sex, administrative gender, and sex (assigned at birth).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         ONC thanks the commenters for their input regarding Sex. Health IT Modules may continue to record and exchange Sex (assigned at birth). Historically, Sex (assigned at birth), administrative sex, and administrative gender have been used to communicate sex which may be used for clinical decision making when the values were obtained from a document at some point in a patient's life or were not based on clinical observations and should not be used for clinical decision making. The addition of Sex allows health IT developers to exchange Sex without relying on document context.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters suggested that ONC remove the “patient demographics and observations” criterion entirely and rely on USCDI to promote the capture, use, and exchange of patient demographic data elements. Others suggested that all data elements listed in the “patient demographics and observations” criterion should be in USCDI prior to inclusion in regulation. These commenters referenced cases where ONC withdrew certification criteria (
                        <E T="03">e.g.,</E>
                         Problem List, Medication List, Smoking Status).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         ONC thanks the commenters and acknowledges that certification criteria have been withdrawn in the past. ONC declines to remove the ”patient demographics and observations” criterion or change the scope of USCDI to include data capture and use.
                    </P>
                    <P>The “patient demographics and observations” certification criterion includes important data elements supporting underserved communities and health equity. The USCDI scope is focused on the exchange of data element values, whereas this certification criterion focuses on health IT capabilities to collect and record certain data. In some cases, the data required to be collected and recorded is not yet in USCDI.</P>
                    <P>
                        <E T="03">Comments.</E>
                         In the HTI-1 Proposed Rule, proposals for § 170.315(a)(5), ONC asked commenters to provide feedback regarding whether Recorded Sex or Gender as defined by the Gender Harmony Project should be incorporated into the § 170.315(a)(5) “patient demographics and observations” criterion. Responses indicate there is not agreement among interested parties, and many open issues remain related to how and when these data should be collected. One commenter suggested that ONC remove the Sex data element entirely and add Recorded Sex or Gender to delineate administrative information from Sex for Clinical Use, which is to be used when making clinical decisions.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         ONC thanks commenters for their thoughtful input and will not finalize the addition of Recorded Sex or Gender to § 170.315(a)(5) due to lack of community consensus. ONC will continue to support maturation of this data element through the Gender Harmony Project at HL7.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters encouraged ONC to work with interested parties to provide clarity on the differences between related data elements to ensure patients' identities are respected while important information for clinical care is captured correctly. Specifically, sharing this information via a patient access API, such as those required by the CMS quality programs for health care providers under Medicare, may cause confusion or distress to a patient. Commenters also noted that care must be taken to ensure privacy controls are in place to protect sensitive, granular health data. This information may be sold or disclosed by an application developer if agreed to in the consumer terms and agreement.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their comments regarding privacy concerns and recognize the importance of addressing the privacy and confidentiality of sensitive information. Recognizing this, the Program establishes the standards, implementation specifications, and functional requirements for health IT to manage and exchange data but does not control the collection or use of data. For more on patient requested restrictions on sharing of their health information, we refer readers to section III.C.10 on modifications to the “view, download, and transmit to 3rd party” certification 
                        <PRTPAGE P="1298"/>
                        criterion in § 170.315(e)(1), which addresses patients' (and their authorized representatives') ability to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213.
                    </P>
                    <HD SOURCE="HD3">Base EHR Definition</HD>
                    <P>We proposed to revise and update the “demographics” certification criterion (§ 170.315(a)(5)), to rename as “patient demographics and observations,” and which is included in the Base EHR definition in § 170.102 (88 FR 23821). This means Health IT Modules would need to be updated to accommodate the additional requirements in the “patient demographics and observations” certification criterion in order to meet the Base EHR definition. We did not receive comments related to updating the Base EHR definition to include the additional requirements in the “patient demographics and observations” certification criterion, so we have finalized this revision as proposed.</P>
                    <P>In addition, because December 31, 2022 has passed, we proposed to revise the Base EHR definition by removing the reference to § 170.315(g)(8) in § 170.102 Base EHR Definition (3)(ii) and replacing the references to § 170.315(g)(10) in § 170.102 Base EHR Definition (3)(ii) and (iii) with a single reference to § 170.315(g)(10) in § 170.102 Base EHR Definition (3)(i). We did not receive comments on this proposal, so we have finalized this revision as proposed.</P>
                    <HD SOURCE="HD3">9. Updates to Transitions of Care Certification Criterion in § 170.315(b)(1)</HD>
                    <P>
                        We proposed to replace the fixed value set for the USCDI data element “Sex” and instead enable health IT developers to specify any appropriate value from the SNOMED CT U.S. Edition code set with the standard specified in § 170.207(n)(2) (88 FR 23821). We proposed that health IT developers can continue using the specific codes for Sex represented in § 170.207(n)(1) for the time period up to and including December 31, 2025. We note that these dates were proposed for the adoption of the associated standards in § 170.207(n), including the expiration of the adoption of the standard in § 170.207(n)(1) on January 1, 2026. As discussed in sections III.A and III.C.11, developers of certified health IT with Health IT Modules certified to criteria that reference § 170.207(n)(1) would have to update those Health IT Modules to § 170.207(n)(2) and provide them to customers by January 1, 2026. We note that, in the 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). ONC has not finalized § 170.213 as proposed in § 170.315(b)(1)(iii)(G)(
                        <E T="03">3</E>
                        ), as § 170.213 references a version of SNOMED CT U.S. Edition that is older than the one referenced in § 170.207(n)(2). We have finalized the reference to § 170.207(n)(2) in § 170.315(b)(1)(iii)(G)(
                        <E T="03">3</E>
                        ) to include the most recent version of SNOMED CT U.S. Edition available at the time of publication of this final rule. Health IT developers may update to a newer version if one exists at effective date of the criterion.
                    </P>
                    <P>
                        We also proposed a conforming update to § 170.315(b)(1) to update the listed minimum standard code sets for Problems in § 170.315(b)(1)(iii)(B)(
                        <E T="03">2</E>
                        ) (88 FR 23821). We proposed that Health IT Modules certified to § 170.315(b)(1) use, at a minimum, the version of the standard specified in § 170.207(a)(1).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         All commenters agreed with the proposal to update the transitions of care certification criterion § 170.315(b)(1)(iii)(G)(
                        <E T="03">3</E>
                        ) to include the adoption of USCDI v3 in § 170.213(b). Some commenters noted that the updated criterion will allow better inpatient—outpatient transitions, especially for community health centers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         ONC thanks commenters for their support to update the transitions of care certification criterion to include the adoption of USCDI v3. We have finalized the adoption of this proposal in this final rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter encouraged ONC to work across HHS to enforce existing CMS and ONC requirements across products and healthcare organizations. The commenter suggests that HHS should extend transition of care data elements for claims data from payers to healthcare organizations offering primary care.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         ONC thanks the commenter for their input. ONC will continue to work with federal partners to promote alignment for these data concepts.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters suggested that the date to support USCDI v3 in Transitions of Care documents should be changed to December 31, 2025, or 24 months after the rule is finalized to allow health IT developers time to incorporate and test USCDI v3 data elements into Health IT Modules and develop appropriate safeguards for sensitive personal health information.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         ONC appreciates concerns expressed about the proposed date to allow for USCDI v3 adoption prior to including USCDI v3 data elements in transition of care documents. We have finalized the adoption of updates to § 170.315(b)(1) with a compliance date of January 1, 2026.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters expressed concern about USCDI data element Sex and its inclusion in patient matching algorithms, suggesting that time of birth is a better matching parameter than Sex. Other commenters suggested that mother's maiden name (in a child's record), birth order, and multiple birth indicators be added to the patient matching requirement.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         ONC thanks commenters for their input concerning appropriate data to include in patient matching algorithms. The transitions of care criterion define the minimum set of data elements to use for patient matching and does not inhibit health IT developers from using other additional data elements.
                    </P>
                    <HD SOURCE="HD3">10. Patient Right To Request a Restriction on Use or Disclosure</HD>
                    <P>In the HTI-1 Proposed Rule, we noted that under the HIPAA Privacy Rule, covered entities, as defined in 45 CFR 160.103, are required to allow individuals to request a restriction on the use or disclosure of their PHI for treatment, payment, or health care operations, although it does not require covered entities to accept such requests, except in certain limited circumstances (See 45 CFR 164.522(a)(1)) and 164.530(i)) (88 FR 23821). The HIPAA Privacy Rule also requires covered entities to implement policies and procedures with respect to PHI that are designed to comply with the standards, implementation specifications, or other requirements of the HIPAA Privacy Rule, including the individual right to request restrictions (See 45 CFR 164.530(i)(1)). We stated that we believe that certified health IT should support covered entities so they can execute these processes to protect individuals' privacy and to provide patients an opportunity to exercise this right to the extent feasible. However, we also noted that patient-directed privacy of data the patient deems sensitive requires attention to specific technology and policy challenges, which we recognize are not easily solved (88 FR 23821).</P>
                    <P>
                        We proposed a new certification criterion in § 170.315(d)(14), an addition to ONC's Privacy and Security Framework under the Program in § 170.550(h), and a revision to an existing “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1) to support additional tools for implementing patient requested privacy restrictions (88 FR 23822 through 23824).
                        <PRTPAGE P="1299"/>
                    </P>
                    <P>We proposed to adopt a new certification criterion “patient requested restrictions” in § 170.315(d)(14) to enable a user to implement a process to restrict uses or disclosures of data in response to a patient request when such restriction is agreed to by the covered entity (88 FR 23822). This criterion was proposed specifically in support of the HIPAA Privacy Rule's individual right to request restriction of certain uses and disclosures (See also 45 CFR 164.522(a)). We proposed that this new criterion in § 170.315(d)(14) would be standards-agnostic, allowing health IT developers seeking to certify a Health IT Module to the criterion flexibility in how they design these capabilities as long as they meet the functional requirements described for certification. We specifically intended the proposed § 170.315(d)(14) to advance the technological means to support clinicians and other covered entities when honoring patient requests for the restriction of uses or disclosure of PHI through certified health IT.</P>
                    <P>We proposed to add the following in § 170.315(d)(14) for this new criterion “patient requested restrictions”:</P>
                    <P>• For any data expressed in the standards in § 170.213, enable a user to flag whether such data needs to be restricted from being subsequently used or disclosed; as set forth in 45 CFR 164.522; and</P>
                    <P>• prevent any data flagged pursuant to paragraph (d)(14)(i) of this section from being included in a subsequent use or disclosure for the restricted purpose.</P>
                    <P>
                        We proposed that “enabl[ing] a user to flag” means enabling the user of the Health IT Module to indicate that a request for restriction was made by the patient and that the user intends to honor the request. We noted that in the case of integration with a Health IT Module certified to the revised criterion in § 170.315(e)(1), that request made by the patient could be in part automated for requests made through an internet-based method. However, the functionality under the proposed new criterion in § 170.315(d)(14) would include the ability for the user to indicate a request made via other means. We noted that such “flags” may leverage use of security labels like those included in the HL7 data segmentation for privacy (DS4P) implementation guides discussed in section III.C.10.b of the HTI-1 Proposed Rule, or other data standards such as provenance or digital signature specifications.
                        <SU>182</SU>
                        <FTREF/>
                         We also noted that the use of such standards or specifications would be at the discretion of the health IT developer, and they would have the flexibility to implement the “enable a user to flag” functionality in the manner that works best for their users and systems integration expectations.
                    </P>
                    <FTNT>
                        <P>
                            <SU>182</SU>
                             For example, the USCDI v3 includes a provenance data class (
                            <E T="03">https://www.healthit.gov/isa/uscdi-data-class/provenance#uscdi-v3</E>
                            ) and submissions in ISA include digital signature as a potential addition to provenance within the USCDI: 
                            <E T="03">https://www.healthit.gov/isa/uscdi-data/signature.</E>
                             Further specifications for provenance data and digital signatures in the context of FHIR-based transactions are also referenced in ISA: 
                            <E T="03">https://www.healthit.gov/isa/representing-data-provenance.</E>
                        </P>
                    </FTNT>
                    <P>
                        We proposed that the developer of a certified Health IT Module, under the proposed standards-agnostic approach, would have the flexibility to implement the restriction on the inclusion in a subsequent use or disclosure via a wide range of potential means dependent on their specific development and implementation constraints (
                        <E T="03">e.g.,</E>
                         flagged data would not be included as part of a summary care record, not be displayed in a patient portal, or not be shared via an API). We proposed and sought comment on several alternatives which would add standards to the proposed new criterion and would specifically leverage HL7 dS4P IGs for the new criterion in § 170.315(d)(14). We also proposed and sought comment on alternate proposals that looked exclusively at the HL7 Privacy and Security Healthcare Classification System (HCS) Security Label Vocabulary within the HL7 dS4P IGs for a source taxonomy for the “flag” applied to the data (88 FR 23822).
                    </P>
                    <P>We also proposed to modify the Privacy and Security Framework in § 170.550(h) to add the proposed new criterion. Specifically, we proposed to modify § 170.550(h)(iii) in reference to the certain of “care coordination” certification criteria in § 170.315(b); § 170.550(h)(v) in reference to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1); and to § 170.550(h)(viii) in reference to the § “application access” certification criteria at § 170.315(g)(7) through (g)(9) and the “standardized API for patient and population services” certification criterion at § 170.315(g)(10).</P>
                    <P>We proposed that the new “patient requested restrictions” certification criterion in § 170.315(d)(14) would be required for the Privacy and Security Framework by January 1, 2026.</P>
                    <P>We also proposed a modification to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1) to support patients' ability to leverage technology to exercise their right to request restrictions of uses and disclosures under the HIPAA Privacy Rule. We proposed that a Health IT Module certified to the criterion in § 170.315(e)(1) must also enable an internet-based approach for patients to request a restriction of use or disclosure of their EHI for any data expressed in the USCDI standards in § 170.213. Specifically, we proposed to modify § 170.315(e)(1) to add a paragraph (iii) stating patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213.</P>
                    <P>We proposed that conformance with this update to the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1)(iii) would be required by January 1, 2026, for Health IT Modules certified to § 170.315(e)(1). Consistent with our proposals in sections III.A and III.C.11 of the HTI-1 Proposed Rule, developers of certified health IT with Health IT Modules certified to § 170.315(e)(1) would have to update those Health IT Modules to § 170.315(e)(1)(iii) and provide them to customers by January 1, 2026.</P>
                    <P>We did not propose any changes to the current certification criteria for “security-tags—summary of-care—send” and “security-tags—summary of care—receive” in § 170.315(b)(7) and § 170.315(b)(8) respectively; however, we noted that the inclusion of the proposed new certification criterion in § 170.315(d)(14) into the Privacy and Security Framework in § 170.550(h) would mean that the proposed new certification criterion would be applicable for Health IT Modules certified to the “security tags—send” and “security tags—receive” certification criteria as well (88 FR 23822-23823). We sought comment on whether those certification criteria should also be directly modified in alignment with the proposals described in this section (88 FR 23823).</P>
                    <P>
                        We sought comment on the capabilities we have proposed for the new criterion in relation to the HIPAA Privacy Rule individual right to request restriction of uses and disclosures of PHI. We specifically sought comment on whether the proposed new criterion should include additional functions to better support compliance with the HIPAA Privacy Rule individual right to request restriction of uses and disclosures of PHI. We also sought comment on whether the proposed new criterion should, for example, include capabilities to support HIPAA Privacy Rule provisions for emergency disclosures in § 164.522(a)(1)(iii) and (iv) or termination of a restriction under § 164.522(a)(2).
                        <PRTPAGE P="1300"/>
                    </P>
                    <P>We sought public comment on each part of this proposal—the new criterion in § 170.315(d)(14), the inclusion of the request capability for patients in § 170.315(e)(1), and the requirements with the Privacy and Security Framework in § 170.550(h)—both separately and as a whole. We specifically sought comment on the feasibility of each part in terms of technical implementation and usefulness for patients and covered entities using these capabilities. We sought comment on the health IT development burden associated with implementation of the capabilities including for the individual certification criterion referenced in the Privacy and Security Framework in § 170.550(h).</P>
                    <P>In addition, we sought comment on any unintended consequences that the new criterion in § 170.315(d)(14) or the addition to the Privacy and Security Framework in § 170.550(h) might place on patients, clinicians, or other covered entities using certified health IT. We sought comment on whether, and by how much, the use of this criterion as part of broader privacy workflows might represent a reduction in manual effort for covered entities, a positive impact on uptake by patients, or other benefits such as supporting documentation of restrictions as required under the HIPAA Privacy Rule in § 164.522(a)(3).</P>
                    <P>Finally, we sought comment on methods by which we might quantify the development burden and costs as well as the potential benefits or future cost savings for the new criterion in § 170.315(d)(14), the new functionality in the existing criterion in § 170.315(e)(1), and the addition to the Privacy and Security Framework in § 170.550(h).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Overall, in response to our new proposal for Patient Requested Restrictions Criterion in § 170.315(d)(14), we received mixed input for our proposals and our alternative proposals from interested parties. Comments ranged from full support to limited support expressing various technical and policy considerations all the way to full opposition because of technical, policy, and patient care concerns. Multiple commenters expressed support for the intent behind the proposal, noting its potential to empower patients to take ownership of their data, while ensuring that providers are not engaging in information blocking for automated data flows and expressed support for the development and implementation of data segmentation technology. Multiple commenters supported giving patients a reasonable opportunity and the technical capability to make informed decisions about the collection, use, and disclosure of their EHI, noting that the functionality is increasingly necessary for ensuring patient trust.
                    </P>
                    <P>However, in most instances where support was indicated, it was conditional. In these instances, commenters indicated concern with the implementation of the proposal, noting that if ONC were to finalize the proposal then it should be mindful of numerous considerations and challenges. Concerns ranged across many broad policy and technical topics including but not limited to implementation feasibility, unintended consequences such as impacts on patient safety and provider burden, implementation timeline and approach, importance of patient education, and intersections with existing information blocking policy as well as the Trusted Exchange Framework and Common Agreement (TEFCA).</P>
                    <P>Multiple commenters questioned the readiness of real-world tested, national standards and specifications for this proposal. One commenter suggested that developers should be given flexibility in implementing the criterion, given the breadth of activities, workflows and features in which patient data is used. Some suggested that adopting a standards-agnostic approach will allow health IT developers to determine appropriate implementation in their own systems and could lead to the future development of new, consensus-based standards informed by robust real-world implementation experience across a broad set of developers and health care provider organizations. However, multiple commenters recommended the criterion be standards-based, as based on past examples, a standards-agnostic approach would likely not successfully lead the private sector to come to consensus on their own. Some commenters indicated support for HL7 FHIR DS4P IG but felt it was not clear that it has been adequately tested and deployed in the field. Such commenters stated that ONC should move forward with support for implementations and test them before deploying as a requirement. One commenter indicated ONC should instead look at FHIR for future rulemaking. Multiple commenters recommended that we focus on establishing, with the relevant Standards Development Organizations (SDOs) as well as other relevant groups, a common infrastructure that enables patients to only document their consent rules once, while having a common definition of all relevant privacy rules across US jurisdictions. Multiple commenters recommended federally funded connectathons and other policy-driven approaches to stimulate the developer community to implement toward a particular use case with the purpose of advancing standards development.</P>
                    <P>We also received comments indicating strong opposition to the new proposal for patient requested restrictions criterion in § 170.315(d)(14). Commenters opposing the proposal shared a similar sentiment to those supporting the proposal provided certain conditions were met. These commenters stated that it is not feasible for developers to support every permutation on the use of data that a patient might request and that the proposed criterion may not provide enough control to help patients manage the complexities of their information. Commenters highlighted the complexity of managing and scaling a consent management infrastructure, especially across all the data sources where the patient's data is available. Others noted this proposal runs a high risk of allowing for a wide variety of misaligned implementation, and some felt it would increase burden and undermine benefits of interoperability.</P>
                    <P>Multiple commenters suggested that, if adopted, the new proposed criterion in § 170.315(d)(14) should be optional and that adoption of the criterion within the privacy and security framework in § 170.550(h) should not be required before CY 2030. Commenters noted that significant work would be required by health IT developers, including reconfiguration of existing EHR systems as well as other interconnected systems related to treatment, payment and operations and that ONC should allow for a 3-year implementation cycle, 2 years to develop, test and certify, and at least 1 year to roll-out the proposed criterion to customers and update workflows. In response to our request for comment related to the development burden (88 FR 23823), commenters estimated up to one-million hours for preliminary development and rollout, plus additional ongoing maintenance requirements.</P>
                    <P>
                        We received several comments regarding how to achieve policy goals through alternative approaches and factors that should be taken into consideration—including several that are out of scope of ONC authorities, but informative of the need for alignment to related privacy laws. Several commenters stated ONC should better align with other regulators and have more explicit workflows on privacy and patient consent before adopting this proposed certification criterion in § 170.315(d)(14). One commenter also 
                        <PRTPAGE P="1301"/>
                        suggested that this criterion's functionality support providers implementing information sharing practices in compliance with potential future policies to protect sensitive health information regarding “highly politicized lawful health care services.” Multiple commenters recommended introducing a functional requirement aligning with the HIPAA right to request corrections and amendments to erroneous information to ensure patients have an easy path to requesting corrections or amendments to their PHI through patient portals and APIs. They also felt that this would drive participation in standardization efforts through independent patient-led governance bodies. One commenter suggested that this work be funded and supported by the institutions sharing the data and driving these exchanges, and the commenter encouraged use of established patient-created resources to evaluate fairness of engagement with patient communities. Several commenters focused on our proposals in relation to other related regulations. These commenters indicated that ONC should work with other agencies to focus on ensuring there are streamlined and complementary privacy regulations. They additionally commented that any new privacy related regulation gets compared and cross referenced across existing and pending ones to support policy alignment.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their thoughtful input addressing both the entirety of the proposals and specific areas of concern. As noted in the HTI-1 Proposed Rule (see, for example, 88 FR 23821), we proposed requirements for Health IT Modules certified under the Program to support workflows and specifications that would enable an individual to exercise their right to request restriction of uses and disclosures under the HIPAA Privacy Rule. We expressed our concerns about feasibility, timelines, and the overall complexity of the workflows and the related capabilities associated with this right as well as our intent to propose several options for consideration by the healthcare and health IT communities. Based on the mixed input we received on the proposed new criterion in § 170.315(d)(14) and the inclusion of the criterion in the privacy and security framework in § 170.550(h), and the strong concerns regarding its implementation feasibility by interested parties opposing these proposals, we have concluded that we should not finalize the proposals at this time. Our decision to not finalize the criterion in § 170.315(d)(14) is informed by the range of comments expressing concern with successfully implementing the proposal. In particular, there was no clear consensus on whether and how to proceed either with immature and untested standards or without the required use of specific standards for the certification criterion at § 170.315(d)(14). We agree with the concerns on the high risk of allowing Health IT Modules to implement a wide variety of misaligned standards and implementation specifications, as well as increased burden on developers of certified health IT, care providers, health information exchange networks, and a high probability of confusion for patients.
                    </P>
                    <P>We note that those supporting our proposals for § 170.315(d)(14) did so to varying degrees, often extending conditional support while raising the same broad technical and policy considerations and concerns as those opposed to the proposal. Outright support on § 170.315(d)(14) as proposed, or for the various alternate proposals, was not as common as conditional support or opposition. The specific suggestions for such conditional support were varied and would introduce substantial additional detailed specification well beyond the scope of our proposal and the standards in the alternate proposals. Based on this input, there is no clear and consistent approach at this time to effectively address all commenter concerns. Therefore, we have not finalized the specific proposal to adopt a new certification criterion in § 170.315(d)(14). We also have not finalized corresponding modifications related to this proposed criterion's in ONC's Privacy and Security Framework in § 170.550(h). We will continue to encourage and engage with industry and standards development community efforts to advance standards supporting privacy workflows and to monitor the continued evolution of the HL7 DS4P IGs to consider new criteria in future rulemaking.</P>
                    <P>
                        In consideration of those commenters who articulated full support, we recognize the importance of empowering patients to take ownership of their data and continue to support efforts to develop the technical capability for patients to leverage certified health IT to take affirmative action regarding the collection, use, and disclosure of their EHI. We note that we have maintained the existing criteria in § 170.315(b)(7) and § 170.315(b)(8) which support the application and persistence of security labels for document-based exchange and reference the standards adopted in § 170.205(o)(1), the HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 (HL7 CDA DS4P IG) incorporated by reference in § 170.299. These two criteria require a Health IT Module to (1) enable a user to create a summary record that is tagged as restricted and subject to restrictions on re-disclosure and (2) enable a user to receive a summary record that is tagged as restricted and subject to restrictions on re-disclosure and to preserve privacy markings. The use of Health IT Modules certified to these two criteria can support privacy and security labels based on consent and with respect to sharing and re-disclosure restrictions. As noted, these existing criteria utilize the HL7 CDA DS4P IG, and include the use of the taxonomy of reference (HCS Security Label Vocabulary) for the purposes of applying and identifying standardized security labels on health information at the document, segment, or data element level. These existing certification criteria can be leveraged during transitions of care and sending/receiving summary of care records (
                        <E T="03">i.e.,</E>
                         combined with Health IT Modules certified to § 170.315(b)(1)) and we encourage purchasers of certified health IT to explore the use and incorporation of these capabilities in their Health IT Modules.
                    </P>
                    <P>
                        We recognize the concerns of both commenters supporting the application of standards and those identifying a lack of readiness and gaps in the standards for the disposition of a disclosure request based on our proposed new criterion. We also recognize those commenters who advised a longer implementation timeline to refine and test standards. While we considered delaying the implementation of our proposal to 2030, or beyond, we believe that Health IT Modules certified to § 170.315(b)(7) and (b)(8) that use the HL7 CDA DS4P IG may serve as a balanced approach to address these disparate concerns by applying the standard where feasible, while allowing broad flexibility for health IT developers to implement functionalities where the standard is silent on core processes. We will continue to monitor uptake of the existing certification criteria at § 170.315(b)(7) and § 170.315(b)(8), as well as continue to work with the healthcare, health IT, and standards community to advance and evaluate the readiness and potential adoption in future rulemaking of the related HL7 FHIR DS4P IG, which is intended to support the same security label taxonomy (HCS Security Label Vocabulary) for health information 
                        <PRTPAGE P="1302"/>
                        exchange via standards-based APIs using the FHIR standard.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received many comments in relation to our proposal to update the existing “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1), to add § 170.315(e)(1)(iii) to support additional tools for implementing patient requested privacy restrictions (88 FR 23822 through 23824) through the inclusion of an “internet-based” method for patients to request a restriction. Commenters were overwhelmingly supportive of the proposal to provide a means for patients to make a restriction request via Health IT Module. However, commenters expressed a wide range of related concerns ranging from the documentation of the request to potential consequences to consider when processing a patient's requests for restriction.
                    </P>
                    <P>One commenter expressed concern that the HIPAA Privacy Rule does not (with certain exceptions) require a covered entity to restrict disclosure of an individual's PHI if so requested. Instead, the covered entity is required to have a process for approving or denying the request, and that decision is not under the individual's control. One commenter recommended that the certification criterion respect the individual's request for privacy regardless of the covered entity's perspective. However, another commenter noted that requiring the covered entity's approval ensures that important health information is still available when medically necessary while balancing patient privacy and security concerns. One commenter stated that clinicians may have a better understanding than individuals regarding which health data is relevant for their care. Commenters also expressed concern regarding an obligation to accept an individual's request for restriction. One commenter questioned how the lack of restriction on timelines for the request—such as the lookback period for the data or the length of time for which the restriction would be applicable—could impact the clinician's ability to make a reasoned judgment. Another commenter expressed a number of legal concerns relating to concerns that clinicians may have to defend refusals to comply with a patient's request for restriction, or that compliance with the patient's request which could place them in legal jeopardy for fraud, professional misconduct, or criminal charges.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their input and support of our proposal to include an internet-based method for an individual to request restriction of uses and disclosures consistent with their right under the HIPAA Privacy Rule. We have finalized this proposed revision to the existing “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1) to support additional tools for implementing patient requested privacy restrictions (88 FR 23822 through 23824) through the inclusion of an “internet-based” method for patients to request restriction. Specifically, we have finalized in § 170.315(e)(1)(iii) a requirement that Health IT Modules support patients (and their authorized representatives) to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. We have also finalized that conformance with this paragraph is required by January 1, 2026.
                    </P>
                    <P>In response to comments on whether a patient or health care provider may be best suited to determine if data should be private, or a covered entity's obligation to accept a patient's request, we reiterate our statement from the HTI-1 Proposed Rule that our intent is to advance technologies that support requirements already extant under the HIPAA Privacy Rule (88 FR 23821). In the HTI-1 Proposed Rule, we described that the HIPAA Privacy Rule provides individuals with several rights intended to empower them to be more active participants in managing their health information. These include the right to access certain health information maintained about the individual; the right to have certain health information amended; the right to receive an accounting of certain disclosures; the right to receive adequate notice of a covered entity's privacy practices; the right to agree or object to, or authorize, certain disclosures; the right to request restrictions of certain uses and disclosures; and provisions allowing a covered entity to obtain consent for certain uses and disclosures. Under the HIPAA Privacy Rule, covered entities as defined in 45 CFR 164.530(i) are required to allow individuals to request a restriction on the use or disclosure of their PHI for treatment, payment, or health care operations and to have policies in place by which to accept or deny such requests (See 45 CFR 164.522(a)(1)(i)(A) and (B)). The HIPAA Privacy Rule does not specify a particular process to be used by individuals to make such requests or for the entity to accept or deny the request. However, we believe that certified health IT should—to the extent feasible—support covered entities so they can execute these processes to protect individuals' privacy and to provide patients an opportunity to exercise this right (88 FR 23821).</P>
                    <P>We further stated that identifying which health data are defined as “sensitive” may vary across federal or state laws and may further vary based on an individual's perspective. Thus, the concept of “sensitive data” is dynamic and specific to the individual. Patient populations that have historically been subject to discrimination may identify a wide range of demographic information as sensitive, including race, ethnicity, preferred language, sex, sexual orientation, gender identity, and disability status—or patients may want to restrict health data that they view as sensitive, such as behavioral health or reproductive health-related data. These considerations from an individual's perspective may not always coincide with a health care provider's perspective. However, we believe that facilitating the ability of a patient to request such a restriction, in addition to addressing patient considerations, may also provide additional context for health care providers engaged in discussions with patients about their health information, sensitivities, and related concerns.</P>
                    <P>In response to commenters expressing concerns with timelines associated with requests, we decline to specify any limitations and note that a health care provider might include an option for an individual to specify such information as a part of the internet-based method for requests in § 170.315(e)(1).</P>
                    <P>For commenters expressing concerns related to legal liabilities, we reiterate that ONC certifies capabilities of Health IT Modules to perform specific functions, in many circumstances using specific standards. These are generally restricted to technical standards and capabilities. The user of the technology may also need to comply with certain requirements established by federal, state, territory, local or tribal law. Our intent for finalizing a technical means for individuals to request a restriction on their data is to advance tools that support privacy laws, including the HIPAA Privacy Rule right to request a restriction of certain uses and disclosures.</P>
                    <P>
                        We note that the revision adding an internet-based method to make a request that we have finalized as part of § 170.315(e)(1) only supports one component of the HIPAA Privacy Rule. As noted in the HTI-1 Proposed Rule, we emphasize that use of a Health IT Module certified to revised criterion in § 170.315(e)(1) would not, by itself, fully discharge a covered entity's obligations 
                        <PRTPAGE P="1303"/>
                        under the HIPAA Privacy Rule to allow an individual to request restriction of the use or disclosure of their PHI for treatment, payment, or health care operations or to have policies in place to address such requests (88 FR 23826). Further, use of any such certified Health IT Module would not discharge the obligations of a covered entity to meet any other requirements under 45 CFR 164.522. In addition, there may be other applicable laws that affect the exchange of particular information, and those laws should be considered when developing policies that provide individuals with more granular control over the use or disclosure of their PHI.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed support for a patient's ability to manage various aspects related to their restriction requests. Multiple commenters noted that patients should be able to allow data use/exchange with some parties but not others and be able to decide the timing to safeguard patient autonomy and mitigate criminalization risk. Commenters also suggested that the patient should be able to define when a treatment relationship exists with a provider and only allow exchange with those providers who qualify, without explicit consent from the patient. One commenter noted that patients should be able to group data by type or encounter/procedure date or any criteria the patient wishes to impose on data use and exchange. Another commenter recommended allowing patients to decide how long they would like to restrict sensitive data from being shared. Another commenter suggested that we introduce certification requirements focused on granting health care providers the option to segment entire discrete sensitive notes, which allow clinicians to limit access to notes that patients consider sensitive, in a fully self-contained way.
                    </P>
                    <P>With regards to recording patient requests for restriction, we received comments related to the inclusion of additional, relevant information. One commenter sought clarification on whether the requirement includes providing a standard way for a patient to state the purpose for a particular restriction. One commenter highly recommended that we include a certification criterion for the “tracking of patient privacy and disclosure requests” and another suggested that the concepts “request for restriction was made” and “request for restriction was granted” be separated in the requirements, recorded, and permanently associated with the related data. They also recommended that if a request is denied, a rejection reason should be required, retained, and exchanged alongside the related data so the next recipient of the data could potentially decide how to respond to the patient request.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their input and advocacy on behalf of patients. In the HTI-1 Proposed Rule, we did not include proposals for § 170.315(e)(1) to add specific requirements on the format of the “internet-based method” individuals to request restrictions. We also did not specify additional functionality beyond the capability for patients (and their authorized representatives) to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. For example, we did not propose that the function must enable individuals to specifically identify different access roles for individual care team members or that patients be enabled to group health information in different ways, such as by type or encounter/procedure, or that patients be provided the option to segment entire discrete sensitive notes. We proposed an approach that, at minimum, would support a method for patients to request restrictions on PHI uses and disclosures through means related to the function supporting their ability to view, download, or transmit to a 3rd party their health information using certified health IT. We also did not propose specific terminologies to be used for the recording, disposition or notification of acceptance or denial of such requests. We appreciate the insights into enhanced functionalities and the related recording of data associated with such request, but such additional requirements would constitute a significant deviation from the proposed functionality. We do not believe that our proposals represent sufficient notice of the intent to add such requirements in this final rule. However, we will continue to engage with the health IT, standards, health care provider, and patient advocacy communities and to encourage innovative approaches to implementation of the adopted criteria and standards, as well as advancement of additional interoperable privacy standards and functionality. We will also monitor and analyze approaches by health IT developers for real world implementation of the revised criterion, and will consider such information to inform further modifications in future rulemaking.
                    </P>
                    <P>We further note that, while we have not finalized the inclusion of additional capabilities or the application of a specific standard, there are obligations imposed on covered entities under the HIPAA Privacy Rule, if they agree to the requested restrictions, which this functionality may partially support, that health IT developers may consider supporting in related capabilities. For example, the HIPAA Privacy Rule prohibits a covered entity that agrees to a restriction request to use or disclose PHI in violation of such restriction except in certain limited circumstances. We encourage developers of certified health IT certifying Health IT Modules to the revised criterion in § 170.315(e)(1) to consider if there are methods that additional health IT tools could integrate with such Health IT Modules to facilitate these processes. In addition, while we did not propose and have not finalized the use of a standard for the use of security labels, we note that the HL7 CDA DS4P IG adopted in § 170.205(o) and the HCS Security Label Vocabulary that is referenced as part of the HL7 CDA DS4P IG are valuable health IT implementation resources for these purposes. As described in the HTI-1 Proposed Rule (88 FR 23824), the HCS Security Label Vocabulary could serve as the basis for a format-agnostic and transport-mechanism-agnostic standard for the application of security labels and to define the general instructions for security labels for a wide range of use cases including patient requested restrictions. While we are not requiring the use of the HCS Security Label Vocabulary within the revised criterion in § 170.315(e)(1), we recommend health IT developers consider its applicability for this purpose. We further note that the existing criteria “security tags- summary of care send and receive” in § 170.315(b)(7) and (b)(8) for sending and receiving summary of care records with security labels applied at the document, segment, or data element level would potentially support the capabilities commenters describe, including, for example, the ability to label a clinical note in the C-CDA as sensitive.</P>
                    <P>
                        <E T="03">Comments.</E>
                         ONC also received several comments related to health equity and the need for patient-specific education about privacy restrictions. Multiple commenters recommended explaining specific aspects of the proposed functionality to patients such as, how it facilitates individual rights under the HIPAA Privacy Rule, how data is used to improve individual and population outcomes, and the proper role of health IT in protecting the security and privacy of health information. Multiple commenters also recommended providing counseling to patients regarding benefits and risks of restricting data and the impact on their 
                        <PRTPAGE P="1304"/>
                        healthcare outcomes and safety. These comments focused on empowering patients with more granular privacy controls while noting that health literacy is an important part of such control in order to avoid disparities in privacy protection and on overall care quality. These commenters also identified that a person may not share sensitive health data if they do not understand the options for data sharing. One commenter suggested that we clarify if and how patients should be informed about functionality, specifically regarding the ability to request a restriction in multiple ways and with different levels of granularity (rather than just having the binary choice to either share or to not share data globally). Some commenters expressed concern that, if presented with complex data-element sharing options, patients may get confused and simply decide against sharing any data. Another commenter suggested that patients also need to be informed that their requests may be denied. Multiple commenters recommended that we add a requirement that patient-facing certified Health IT Modules include the capability to provide educational materials regarding the patient's options about disclosure and instructions regarding how to change disclosure limitations. Other commenters additionally highlighted the importance of patient education and health literacy, particularly for older-adult and disabled patients who may struggle with cognitive impairments or behavioral health issues. Finally, commenters sought clarification on whether the patient will be informed about who will be notified of restriction requests, as some may be concerned about negatively impacting their relationship with their providers and/or healthcare institutions.
                    </P>
                    <P>In addition to patients, multiple commenters suggested that we provide education and guidance to providers, developers, and the industry as a whole. One commenter noted that provider organizations often do not have a clear mechanism for making patient restriction requests or know how to process/adjudicate/implement them if they do receive requests. Another commenter suggested that the industry will also need significant additional guidance and infrastructure. One commenter suggested that health IT developers should receive guidance regarding standards for developing a process for patient restriction requests. Another commenter noted that without a robust communication, education, and engagement effort, many entities essential to implementing the final rule at medical practices, hospitals, and health systems will be left out. Another commenter recommended that we consider the use of an implementation guide in future rulemaking, and one commenter requested that we provide full guidance on what different types of information should be flagged and how such flags would be addressed in FHIR resources.</P>
                    <P>Some commenters indicated ONC should provide education and work to clarify how this proposal is balanced with information blocking requirements. One commenter noted that confusion about information blocking often results in compliance officers, administrative personnel, in-house attorneys, and policy consultants misinterpreting regulations. They relayed feedback that some health IT developers refuse to provide patients or physicians granular controls over medical information. The commenter noted that compliance with the information blocking regulation is overriding compliance with other, more protective laws and rules, and they recommend that we adequately educate those involved in interpretating, implementing, and operationalizing our policies. Another commenter also requested that we address overlaps with information blocking, how and when to implement Notices of Privacy Practices by providers, and other healthcare workflow considerations that could allow this criterion to be misinterpreted and potentially abused. A commenter also stated that patients should be educated about information blocking and that patient facing tools should be held to similar requirements for access, privacy, and security as certified health IT products.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for the thoughtful consideration of the impacts of our proposals. As we noted in the HTI-1 Proposed Rule (see, for example, 88 FR 23748), health equity considerations are a driving force behind our proposals. We described the importance of expanding the interoperability of health data that is essential to identifying health disparities, measuring quality, addressing gaps in care access and outcomes, providing patient-specific preventative care and intervention, and supporting researchers in their ability to address the risk of unintended bias in clinical guidelines that may exacerbate disparities (88 FR 23821). We also described how important it is to ensure that with the expansion of exchange of granular health equity data comes expanded needs for thoughtful and deliberate privacy policies to support and protect patients (88 FR 23821). We discussed how ONC has specifically focused on how health IT can support efforts to reduce healthcare disparities and provide both insights and tools for the purposes of measuring and advancing health equity. This includes specific steps to expand the capabilities of health IT to capture and exchange data that is essential to supporting patient-centered clinical care that is targeted to supporting a patient's unique needs (88 FR 23821). We believe that patients should be empowered to make such decisions for themselves, and that support or education from clinicians might most appropriately be based on clinical impacts and considerations rather than a perceived lack of patient understanding or competency to make informed decisions.
                    </P>
                    <P>
                        We appreciate commenters suggestion that to fully implement the range of potential rights afforded by the HIPAA Privacy Rule, additional guidance, infrastructure, and standards development is needed to process for patient restriction requests. While we agree with the need for future work on technical specifications and implementation guides, we note that the behavior of covered entities and their role in patient education related to the HIPAA Privacy Rule or other privacy laws is outside the scope of ONC Certification Criteria for Health IT. We encourage covered entities using certified health IT to review and follow the obligations defined under the HIPAA Rules and other applicable laws and programs. We likewise encourage all actors who are required to comply with the HIPAA Rules, whether as HIPAA covered entities or business associates, to know and to comply with all of their obligations under the HIPAA Rules. In response to the comment indicating concern for ONC to extend adequate education on information blocking, we note our deliberate focus on developing accessible, user-friendly resources to help inform the effective implementation of these policies. This includes, but is not limited to, Frequently Asked Questions, recorded national webinars, and infographics all accessible on the ONC website.
                        <SU>183</SU>
                        <FTREF/>
                         For discussion of the relationship of privacy laws, including the HIPAA Rules and other laws, to the information blocking regulations, please see section IV.A of this final rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>183</SU>
                             ONC website: 
                            <E T="03">HealthIT.gov</E>
                             “Information Blocking”. 
                            <E T="03">https://www.healthit.gov/topic/information-blocking.</E>
                        </P>
                    </FTNT>
                    <P>
                        Finally, we appreciate commenters' suggestions about ONC's role in educating patients about health IT capabilities and standards as they relate 
                        <PRTPAGE P="1305"/>
                        to the privacy and security of health information. We are committed to continued public engagement for that purpose.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received mixed feedback on the implementation timeline proposed for health IT developers to comply with any new or revised criteria. In general, commenters (both those opposed to and those supportive of the implementation timelines proposed) address the proposed timelines for updates to the criterion in § 170.315(e)(1) within the context of the implementation burden for that proposed revision and the proposed new criterion in § 170.315(d)(14) together. Multiple commenters expressed concerns that the overall implementation timeline is too aggressive. One commenter noted that if the scope of the proposed new and revised criteria were not narrowed and a holistic effort to also address updates to consent policies is not pursued, a significantly longer implementation period will be required (
                        <E T="03">i.e.,</E>
                         four years or longer). Commenters consistently noted that a development project for the revised criterion in § 170.315(e)(1) in addition to the proposed new criterion in § 170.315(d)(14) would likely require two to three years to code and test and another one to two years for healthcare organizations to implement.
                    </P>
                    <P>
                        Some commenters shared feedback regarding how to make the proposed implementation timeframe more feasible. Multiple commenters suggested that if we narrow the scope to a limited set of USCDI v3 data elements in § 170.315(e)(1) for which restrictions can be requested and clearly and narrowly define the set of restrictions that certified health IT must support (
                        <E T="03">e.g.,</E>
                         restricting the specified data from being accessed by proxy users of the patient portal) in the proposed criterion in § 170.315(d)(14), two years from the publication of a final rule would be feasible. Another commenter requested that we take an incremental approach and start with a low risk, target use case for the effective date of January 1, 2026. This would allow developers and providers to test, learn from and build on this capability over time at both the developer and user levels to address potential issues and risks.
                    </P>
                    <P>Conversely, some commenters felt the timeframe would be difficult to operationalize and expressed concerns regarding the implementation timeline as being too aggressive. Multiple commenters noted that the proposed criterion would not be finalized until after the development and finalization of the USCDI v3, which ONC released July 2022, so there would not be perfect alignment between the use of USCDI v3 and the applicability of our proposed new and revised criteria. Some commenters recommended that ONC should have a constrained scope of USCDI subject to the tagging and to start with a more focused set of the most relevant data elements in the USCDI thus excluding certain sensitive data from what is shareable from within the USCDI until the criterion is fully operationalized. Commenters encouraged “control” or “consent” as an over-arching principle to be timed along with USCDI's expansion to more person-centered information and concepts. Commenters noted this alignment is essential for EHR developers to have the incentive to give users control over their preferences and for physicians be able to honor patients' expressed preferences related to sensitive, life-changing, or abnormal results. In one instance, a commenter also indicated that if ONC were to finalize this proposal then it should reconsider implementation to an earlier requirement date of January 1, 2024, to ensure that operationalizing patient requested restrictions is an immediate priority for software developers if finalized.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their input and consideration of implementation needs and challenges. As previously noted, we have not finalized the proposed new criterion at § 170.315(d)(14) nor the corresponding changes to § 170.550(h). We have only finalized the revisions to the criterion in § 170.315(e)(1). We believe that the reduced scope of the changes we have finalized—focusing on the revised criterion in § 170.315(e)(1) and outlining our commitment to encourage the further adoption, use, and advancement in support of numerous care settings and use cases of the existing criteria in § 170.315(b)(7) and (b)(8) for sending and receiving health information with security labels—should help mitigate the concerns over scale, implementation timeframes, and feasibility. We also believe this approach is appropriate to supporting the advancement of health IT for privacy workflows that place importance on the need to empower patients with agency and control of their data, while acknowledging real challenges, including but not limited to scale and feasibility, as described earlier including from those in support of our proposals. We also agree with commenters that the revisions to the criterion in § 170.315(e)(1) for use of the USCDI v3 are finalized to occur at the same time as the revisions to the criterion in § 170.315(e)(1) described in this section. We have finalized that these revisions to the criterion in § 170.315(e)(1) align with the updates made to USCDI, as discussed in section III.C.1 of this final rule, so that the functionality is synchronized with the USCDI v3 including any new or updated data elements.
                    </P>
                    <P>We have finalized our proposal to revise the criterion in § 170.315(e)(1) as proposed, with the specific revision in § 170.315(e)(1)(iii). Pursuant to other policy decisions discussed elsewhere in this final rule on compliance timing, we have adopted our proposal that conformance with this new paragraph will be required for Health IT Modules certified to § 170.315(e)(1) by January 1, 2026.</P>
                    <HD SOURCE="HD3">11. Requirement for Health IT Developers To Update Their Previously Certified Health IT</HD>
                    <P>In the HTI-1 Proposed Rule, we proposed to make explicit in the introductory text in § 170.315 that health IT developers voluntarily participating in the Program must update their certified Health IT Modules—including when new standards and capabilities are adopted—and provide that updated certified health IT to customers in accordance with the timelines defined for a specific criterion or standard where included, such as via cross-reference, in § 170.315 (88 FR 23827). We proposed that health IT developers with health IT certified to any of the certification criteria in § 170.315 would need to update their previously certified Health IT Modules to be compliant with any revised certification criterion adopted in § 170.315 (please see section III.A.2 of this final rule for discussion of the adopted definition of revised certification criterion (or criteria)), including any certification criteria to which their Health IT Modules are certified that reference new standards adopted in 45 CFR part 170 subpart B, and capabilities included in the revised certification criterion. Health IT developers would also need to provide the updated health IT to customers of the previously certified health IT according to the timelines established for that criterion and any applicable standards (88 FR 23827).</P>
                    <P>
                        We noted that in addition to supporting the goals of the Program, we believe this approach will help to advance interoperability. We stated that requiring health IT developers who voluntarily participate in the Program to update Health IT Modules to revised certification criteria (including new and revised standards) can help to advance capabilities for access, exchange, and 
                        <PRTPAGE P="1306"/>
                        use of EHI for authorized use under applicable State or Federal law. In addition, we explained that ensuring health IT developers voluntarily participating in the Program provide such updates to customers will help to enable the secure exchange of EHI with, and use of EHI from, other health information technology without special effort on the part of the user. We also stated that the proposed timelines serve to support clear and transparent benchmarks for furthering interoperability throughout the health IT infrastructure (88 FR 23827).
                    </P>
                    <P>We explained that the updates to criteria may include technical capabilities such as security enhancements or additional electronic transactions not previously supported for a criterion. These updates may also include an expansion of the data supported by content, vocabulary, and format standards to increase the scope of interoperable EHI (88 FR 23827). The adoption of USCDI v3 and its incorporation into certification criteria through updates to those criteria, as finalized in this rule, means that certified health IT systems will be able to support representation of this health information in a standardized computable format. Updating current systems to incorporate these data elements and providing updated certified health IT to customers would allow users of certified health IT to begin to access, exchange, and use such data without special effort. Over the long term, this advancement of interoperability for certified health IT systems may also have a positive impact on the availability of this essential data and the capability to access, exchange, and use this data across a nationwide health IT infrastructure—including for purposes not yet specifically supported by certified health IT such as clinical research (88 FR 23827).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters outlined concerns regarding the definition of “provide” and, specifically, the preamble language that states, “[we] propose that to `provide' the product means the developer must do more than make the product available and there must be demonstrable progress towards implementation in real-world settings.” Commenters expressed confusion about what “demonstrable progress towards implementation in real-world settings” means and suggested ONC clearly define this phrasing. Commenters also mentioned concerns about how the responsibility of implementing or upgrading to health IT meeting the revised certification requirements ultimately lies with the provider and not the developer.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. We appreciate that the responsibility of implementing a Health IT Module is not solely on the developer. With this final rule, as discussed below, we recognize the potential for variation in how implementation of certified health IT proceeds, including implementation consistent with the agreements, contracts, and licenses that exist between health IT developers and their customers of certified health IT. Overall, our proposed approach is not new or exclusive to the proposed updates in the HTI-1 Proposed Rule, but rather is consistent with the approach ONC adopted for the ONC Cures Act Final Rule updates to the 2015 Edition certification criteria (85 FR 25664). From the effective date of the ONC Cures Act Final Rule through December of 2022, and based on the programmatic technical assistance, developers of certified health IT successfully updated their technology and provided it to customers.
                        <SU>184</SU>
                        <FTREF/>
                         However, as discussed in the HTI-1 Proposed Rule, ONC used the terms “provide” and “make available” interchangeably in the ONC Cures Act Final Rule, and subsequent technical assistance (including through correspondence and via public forums) was required to support clarity and achieve that transition (88 FR 23828). We also noted in the HTI-1 Proposed Rule that “provide” does not imply that the Health IT Module must be in production use across all customers (88 FR 23828). Under this clarification for the term “provide,” we have finalized as proposed that “provide” does not mean that the Health IT Module must be in production use across all customers. We encourage developers of certified health IT to provide updated Health IT Modules to their customers—and support them in their implementation of such updated modules—in the manner most appropriate to support safety, security and interoperability across settings and systems.
                    </P>
                    <FTNT>
                        <P>
                            <SU>184</SU>
                             See ONC 
                            <E T="03">Achieving a Major Milestone: Health IT Developers Certify to Cures Update</E>
                              
                            <E T="03">https://www.healthit.gov/buzz-blog/health-it/achieving-a-major-milestone-health-it-developers-certify-to-cures-update.</E>
                        </P>
                    </FTNT>
                    <P>It is beneficial or necessary to further define “demonstrable progress toward implementation in real world settings” as the phrasing or concept is not part of the finalized regulatory definition of “provide.” As noted by commenters, the phrasing/concept introduces additional confusion over what might constitute demonstrable progress and whether implementation includes production use.</P>
                    <P>We stated in the HTI-1 Proposed Rule, and continue to maintain, that we do not intend for “provide” to mean either that customers who no longer wish to use a certified Health IT Module must be provided the update or that customers who do choose to use an updated certified Health IT Module must have the updated Health IT Module in production use by the timelines established for the health IT developer (88 FR 23828). We note that there are a number of instances in which a health IT developer will have updated the Health IT Module, but the customer may have declined the update. This can occur when the customer is not yet ready to implement new functionalities, standards, and/or workflows, or when the customer decides that the functionalities, standards, and/or workflows are not relevant to their clinical practice.</P>
                    <P>With consideration of the above explanations, we have finalized the term “provide” with a further clarification that “provide” is binary. That is, the updated Health IT Module is either provided to customers (respective of customer choice) by the timeline established, or it is not. Further and accordingly, we have also finalized that a health IT developer must update a Health IT Module as described and provide customers with updated Health IT Modules in order to maintain certification of the Health IT Module. Consistent with the definition of interoperability and the Assurances Condition and Maintenance requirements discussed in section III.D, the certified Health IT Module must be able to support all the capabilities to which it is certified, and such capabilities must be provided to the customer for use without special effort by the end of the regulatory specified timelines.</P>
                    <P>
                        We also note that we proposed to include the definition of “provide” in § 171.102, which stated that “
                        <E T="03">Provide</E>
                         is defined as it is in § 170.102.” We did not intend to define “provide” in part 171 of the HTI-1 Proposed Rule. Therefore, in this final rule, we have not finalized the revision to add the definition of “provide” in § 171.102.
                    </P>
                    <P>
                        We have finalized in § 170.315 for all revised certification criteria and in 45 CFR part 170 subpart B for each applicable standard, as proposed, that a Health IT Module may be certified to either the existing certification criterion or the revised certification criterion until the end of the transition period when the prior standard(s) and/or certification criterion no longer meet certification requirements. During this time period, existing customers may 
                        <PRTPAGE P="1307"/>
                        continue to use the certified health IT they have available to them and can work with their developers to implement updates in a manner that best meets their needs consistent with the established regulatory timeframes. Finally, as with the 2015 Edition Cures Update, in order to support effective communication of the updates, we will implement a practical approach to facilitate transparency using the Certified Health IT Product List (CHPL),
                        <SU>185</SU>
                        <FTREF/>
                         which is the tool that health care providers and the general public may use to identify the specific certification status of a certified health IT product at any given time, to explore any certification actions for a product, and to obtain a CMS Certification ID for a product, which is used when participating in some CMS programs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>185</SU>
                             ONC Certified Health IT Product List: 
                            <E T="03">https://chpl.healthit.gov.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters voiced concerns about how the HTI-1 Proposed Rule aligns with CMS's Promoting Interoperability Program—specifically, the impact on the timing of when hospitals and clinicians implement or upgrade an EHR in order to comply with CMS regulations.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We have worked closely with CMS for more than a decade to ensure alignment between our Program and CMS programs, including the Medicare Promoting Interoperability Program and the Quality Payment Program (these programs incorporate the programs previously known as the EHR Incentive Payment Programs, or “Meaningful Use”) and we will continue to do so moving forward. For example, CMS finalized in the CY 2021 PFS final rule (85 FR 84815 through 84828) that health care providers participating in the Medicare Promoting Interoperability Program and eligible clinicians participating in the Quality Payment Program must use certified health IT that satisfies the definitions of CEHRT at 42 CFR 495.4 and 414.1305, respectively, and is certified under the Program, in accordance with the 2015 Edition Cures Update, as finalized in the ONC 21st Century Cures Act Final Rule (85 FR 25642).
                    </P>
                    <P>
                        As part of the CY 2024 PFS Final Rule, CMS finalized revisions to the definitions of CEHRT in §§ 495.4 and 414.1305 for the Medicare Promoting Interoperability Program and for the Quality Payment Program (88 FR 78308 through 79312) in a manner consistent with the “edition-less” approach to health IT certification that we proposed in the ONC HTI-1 Proposed Rule. This included removing references to the “2015 Edition” in the CEHRT definition, and that in order to meet the CEHRT definitions, technology must meet ONC's certification criteria in 45 CFR 170.315 “as adopted and updated by ONC.” CMS stated that these revisions would ensure that updates to the 2015 Base EHR or subsequent Base EHR definition at § 170.102, and updates to applicable health IT certification criteria in § 170.315, would be incorporated into CEHRT definitions, without requiring additional regulatory action by CMS. CMS noted in its final rule that it will continue to determine when new or revised versions of measures that require the use of certified health IT would be required for participation under the Medicare Promoting Interoperability Program and the Quality Payment Program. In determining requirements for any potential new or revised measures, CMS stated it will consider factors such as implementation timelines and provider readiness to inform when CMS proposes requiring participants to complete measures that rely on the use of certified health IT (88 FR 79310). We will continue to work with CMS as we finalize timeline requirements for developers of certified health IT to update and provide certified health IT to their customers so that their customers (
                        <E T="03">e.g.,</E>
                         health care providers) can meet CMS requirements for the use of such certified health IT. We also note that, historically, CMS has included additional guidance for program participants within CMS proposed or final rules (see, for example, 85 FR 84818-84828).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters in general agreed that if a Health IT Module is not updated to new or revised certification criteria, then the Health IT Module should be retired at the “expiration date” of the certification criterion and/or standard. One commenter expressed confusion about using the term “shall update” when it is up to the developer to determine if they want to update their health IT to comply with new or revised certification criteria.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. Participation in the Program is voluntary and, therefore, any “shall” statements within the Program only apply to a health IT developer that is participating and plans to continue to participate in the Program. If a developer participating in the Program intends to no longer support a specific certified Health IT Module, but intends to continue to participate in the Program, previously finalized policies relating to the withdrawal of a Health IT Module or modification of a certificate would remain applicable (88 FR 23828). Otherwise, if a health IT developer participates in the Program and intends to maintain certification of a Health IT Module, the developer will need to comply with the requirements of the Program, including the finalized requirement in the introductory text to § 170.315 stating “[f]or all criteria in this section, a health IT developer with a Health IT Module certified to any revised certification criterion, as defined in § 170.102, shall update the Health IT Module and shall provide such update to their customers in accordance with the dates identified for each revised certification criterion and for each applicable standard in 45 CFR part 170 subpart B.”
                    </P>
                    <HD SOURCE="HD2">D. Assurances Condition and Maintenance of Certification Requirements</HD>
                    <P>In the HTI-1 Proposed Rule, we proposed to establish a new Condition of Certification and accompanying Maintenance of Certification requirements under the Assurances Condition of Certification (88 FR 23828 through 23830). These new requirements would serve to provide the assurances to the Secretary that Congress sought in the Cures Act and further clarify Program requirements that are established under the authority Congress provided in section 3001(c)(5) of the PHSA, as amended by the Cures Act, and discussed in detail in the HTI-1 Proposed Rule (88 FR 23826).</P>
                    <HD SOURCE="HD3">1. Condition of Certification</HD>
                    <P>We proposed in § 170.402(a)(5), that, as a Condition of Certification, a health IT developer must provide an assurance that it will not inhibit a customer's timely access to interoperable health IT certified under the Program (88 FR 23829). To support this assurance, we proposed accompanying Maintenance of Certification requirements, which are discussed below. The Maintenance of Certification requirements define the scope of this Condition of Certification and provide clarity in terms of what it would mean to take the action of “inhibiting,” what constitutes “timely access,” and what is “interoperable health IT certified under the Program” (88 FR 23829).</P>
                    <P>
                        <E T="03">Comments.</E>
                         In general, commenters supported the establishment of a new Condition of Certification and the accompanying Maintenance of Certification requirements. Commenters identified multiple benefits of the proposed requirements such as ensuring timely access to interoperable health IT and promoting the adoption of advanced technologies and capabilities that can enhance patient care and 
                        <PRTPAGE P="1308"/>
                        workflow efficiency. One commenter noted how these requirements will positively impact the community of health centers by ensuring they have access to the latest capabilities and standards.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support. As noted above and discussed in detail in the HTI-1 Proposed Rule (88 FR 23826), these new requirements will serve to provide the assurances to the Secretary that Congress sought and further clarify Program requirements. Interoperable health IT is an underpinning of the Program and particularly the conditions of certification found in the Cures Act and implemented in 45 CFR part 170 subpart D. Congress established support for health IT interoperability beginning with the authority provided in section 3001(c)(5) of the HITECH Act to adopt standards (including implementation specifications and certification criteria) and establish the Program.
                    </P>
                    <P>For purposes of certification and the maintenance of such certification under the Program, a health IT developer will need to provide an assurance that its health IT is certified to the most recently adopted certification criteria and such certified health IT is made available to its customers in a timely manner. These actions are essential because certification criteria, and in particular revised certification criteria (as defined in this final rule), include standards, implementation specifications, and capabilities that support and improve interoperability as that term is defined by the Cures Act and incorporated in 45 CFR part 170. Since the inception of the Program, ONC has updated certification criteria to include the most recent versions of standards and implementation specifications that most appropriately support and improve interoperability at the time of adoption. We do this because as standards and implementation specifications evolve, they, by their very nature, improve interoperability by allowing for more complete access, exchange, and use of all electronically accessible health information. Further, the interoperability definition also focuses, in part, on the secure exchange and use of EHI from other health IT without special effort on the part of the user. The Assurances Condition of Certification is an important piece to supporting and achieving these goals because it seeks assurances from health IT developers that they will not take any actions to inhibit the appropriate access, exchange, and use of EHI. We, therefore, have finalized in § 170.402(a)(5), as proposed that, as a Condition of Certification, a health IT developer must provide an assurance that it will not inhibit a customer's timely access to interoperable health IT certified under the Program.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A handful of commenters expressed concern about how the Maintenance of Certification requirements may be interpreted as mandatory when the decision to participate in the Program is voluntary. One commenter identified the use of the term “shall update” as possibly being misunderstood as an obligation for developers to continue to participate in the Program when, in fact, it is up to the developer to determine if they want to pursue certification or to allow the module to be retired.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their input. Participation in the Program is voluntary. Health IT developers do not have an obligation to continue to participate in the Program. However, as discussed under section III.C.11 “Requirement for Health IT Developers to Update their Previously Certified Health IT,” if a health IT developer does participate in the Program, it needs to comply with the requirements of the Program, including the finalized Assurances Condition and Maintenance of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Two commenters identified difficulties in navigating between the different requirements for certified health IT for ONC and CMS. Both commenters recommended CMS delay the effective date of changes to the definition of CEHRT referenced within CMS programs until the next reporting period or performance year. The commenters stated that this proposed modification would eliminate confusion and promote cross-agency collaboration.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their feedback. We recognize that certain CMS programs, including the Medicare Promoting Interoperability Program and the Quality Payment Program, require the use of technology meeting the CEHRT definitions in 42 CFR 495.4 and 42 CFR 414.1305. The CEHRT definitions cross-reference health IT certification criteria in 45 CFR 170.315, including relevant dates within the certification criteria which define the requirements of the certification criterion.
                    </P>
                    <P>While changes to the definition of CEHRT maintained by CMS are outside the scope of this final rule, we note that, as part of the CY 2024 PFS Final Rule, CMS finalized revisions to the definitions of CEHRT in 42 CFR 495.4 and 414.1305 for the Medicare Promoting Interoperability Program and for the Quality Payment Program (88 FR 78308 through 79312), including specifying that in order to meet the CEHRT definitions, technology must meet the 2015 Base EHR or subsequent Base EHR definition (as defined at 45 CFR 170.102) and other certification criteria in 45 CFR 170.315 “as adopted and updated by ONC.” CMS stated that these revisions would ensure that updates to the 2015 Base EHR or subsequent Base EHR definition at § 170.102, and updates to applicable health IT certification criteria in § 170.315, would be incorporated into the CEHRT definitions, without requiring additional regulatory action by CMS. We also note that CMS stated that it did not agree with separate effective dates in the CEHRT definitions for the use of updated certified health IT products within the Medicare Promoting Interoperability Program or the Quality Payment Program, as recommended by commenters (88 FR 79311). CMS stated that emphasizing the timelines ONC adopts through notice and comment rulemaking for health IT developers to update and provide certified technology to their customers will reduce burden on participants in the Medicare Promoting Interoperability Program and the Quality Payment Program. CMS further stated that it will continue to determine when new or revised versions of measures that require the use of certified health IT would be required for participation under the Medicare Promoting Interoperability Program and the Quality Payment Program and will consider factors such as implementation time and provider readiness to determine when to require reporting on these measures. We agree with CMS' statements on these topics.</P>
                    <P>
                        In order to support effective communication of the updates, we intend to implement a practical approach to supporting CMS program participants and other certified health IT users through the Certified Health IT Product List (CHPL) in the same manner as was implemented for the 2015 Edition Cures Update. As also discussed under section III.C.11 “Requirement for Health IT Developers to Update their Previously Certified Health IT,” the CHPL is the tool that health care providers and the general public may use to identify the specific certification status of a certified health IT product at any given time, to explore any certification actions for a product, and to obtain a CMS Certification ID for a product, which is used when participating in some CMS programs. We note that historically, CMS has included additional guidance for such 
                        <PRTPAGE P="1309"/>
                        program participants within CMS proposed or final rules (see, for example, 85 FR 84818-84828).
                    </P>
                    <HD SOURCE="HD3">2. Maintenance of Certification Requirements</HD>
                    <P>We proposed, in § 170.402(b)(3)(i), that a health IT developer must update a Health IT Module, once certified to a certification criterion adopted in § 170.315, to all applicable revised certification criteria, including the most recently adopted capabilities and standards included in the revised certification criterion (88 FR 23829).</P>
                    <P>We also proposed, in § 170.402(b)(3)(ii), that a health IT developer must provide all Health IT Modules certified to a revised certification criterion to its customers of such certified health IT. We clarified that a customer, for this purpose, would be any individual or entity that has an agreement to purchase or license the developer's certified health IT (88 FR 23829).</P>
                    <P>
                        We proposed separate “timely access” or “timeliness” Maintenance of Certification requirements for each of the two proposed Maintenance of Certification requirements above that would dictate by when a Health IT Module must be updated to revised certification criteria, including the most recently adopted capabilities and standards; and by when a Health IT Module certified to a revised certification criterion, including the most recently adopted capabilities and standard, must be provided to the health IT developer's customers. We proposed, in § 170.402(b)(3)(iii), that unless expressly stated otherwise in 45 CFR part 170, a health IT developer must complete the proposed “update” and “provide” requirements according to the following proposals. First, we proposed, in § 170.402(b)(3)(iii)(A), that a health IT developer must update and provide a Health IT Module by no later than December 31 of the calendar year that falls 24 months after the effective date of the final rule adopting the revised certification criterion or criteria. Second, we proposed that the “provide” requirement would need to be completed within this same timeframe for customers of the previously certified health IT that must be updated under the “update” proposal. However, we proposed deviations to this timeframe because the “provide” requirement applies to all Health IT Modules that are certified to a criterion that meets the revised certification criterion definition (
                        <E T="03">i.e.,</E>
                         not just health IT previously certified to a `prior version' of a revised certification criterion) and to 
                        <E T="03">new</E>
                         customers of health IT certified to revised certification criteria (88 FR 23829 through 23830).
                    </P>
                    <P>
                        In all the above circumstances, we proposed that health IT certified to revised certification criteria must be provided to all customers, including new customers (
                        <E T="03">i.e.,</E>
                         new to the capabilities), of health IT developers under the Program within reasonable timeframes (88 FR 23830).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Multiple commenters supported the Assurances Condition and Maintenance of Certification requirements. One commenter suggested health IT developers be required to provide all current and new customers with the most current version of a certified Health IT Module. Additionally, the commenter recommended that all health IT developers who have chosen not to comply with new or revised certification standards send a communication to customers in order to better inform such customers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support. We have finalized in § 170.402(b)(3)(i), as proposed, that a health IT developer must update a Health IT Module, once certified to a certification criterion adopted in § 170.315, to all applicable revised certification criteria, including the most recently adopted capabilities and standards included in the revised certification criterion. For clarity, `
                        <E T="03">applicable</E>
                         revised certification criteria' includes those certification criteria to which the Health IT Module was previously certified that meet the definition of a revised certification criterion as finalized in this rule (please see section III.A.2 of the preamble, including Table 1, and “revised certification criterion (or criteria)” under § 170.102 of the regulation text for the definition of revised certification criterion (or criteria)). Equally important, and, as stated above, to meet the requirement, the Health IT Module will need to be updated to the most recently adopted capabilities and standards included in the revised certification criterion. Second, we have finalized, in § 170.402(b)(3)(ii), that a health IT developer must provide all Health IT Modules certified to a revised certification criterion to its customers of such certified health IT. As noted above, a customer, for this purpose, is any individual or entity that has an agreement to purchase or license the developer's certified health IT.
                    </P>
                    <P>
                        In response to the comment about sending a communication to customers by a health IT developer not complying with the “update and provide” requirements, we note that the developer would, under the commenter's described circumstances, violate these new Maintenance of Certification requirements and the Condition of Certification we have finalized at § 170.402(a)(5), by 
                        <E T="03">inhibiting</E>
                         a customer's timely access to interoperable health IT certified under the Program. As such, the developer will have committed non-conformities under the Program, unless the health IT developer did so for a permissible reason as described in section III.C.11 (for example, a developer of certified health IT would not be required to provide updated certified health IT to any customer that elected to decline the update for any reason; or a health IT developer's exercising its ability to reduce the scope of a certification while not under ONC-ACB surveillance or ONC direct review). Because we did not propose a requirement that health IT developers who have chosen not to comply with new or revised certification standards send a communication to customers in order to better inform providers and hospitals, we have not accepted this recommendation. However, if the developer committed a non-conformity, the Program process for correcting the non-conformity may involve notification to all customers.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested additional information regarding when, as proposed, a regulatory exception (“unless expressly stated otherwise in 45 CFR part 170”) to the 24-month criteria might be applied by ONC in § 170.402(b)(3)(iii)(A). Commenters outlined how a possible exception creates additional timelines in an environment where competing priorities between meeting deadlines associated with ONC requirements and the requirements under CMS regulations already exist. A few commenters requested ONC provided explicit guidelines about when a regulatory exception to the “24 months plus X” requirement might be applied. One commenter expressed concern about how this proposed regulatory exception may negatively impact development roadmaps and the ability to fulfill requests falling outside of non-regulatory functionality. Further, multiple commenters expressed concerns about the proposed deadlines and the implications these timeframes have on developers and providers. Commenters stressed the importance of having 18-24 months to address any new or revised certification requirements and identified the December 31st date outlined in the HTI-1 Proposed Rule as a specific concern. One commenter specifically stated 
                        <PRTPAGE P="1310"/>
                        “[g]iven requirements on the implementation end of the cycle, vendors must have 24 months prior to general availability to properly develop and certify their solutions.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' feedback. For purposes of regulatory clarity, we have revised the proposed “timeliness” provision in § 170.402(b)(3)(iii)(A). We have modified the proposed timeliness requirement to state, “a health IT developer must complete the “update” and “provide” requirements consistent with the timeframes specified in part 170” (§ 170.402(b)(3)(iii)(A)). This means that the compliance dates included in the certification criteria in § 170.315 and standards in subpart B will establish when health IT developers need to comply with these Maintenance of Certification requirements. In § 170.402(b)(3)(iii)(B), we have finalized the provision that health IT developers will still have up to 12 months, at a minimum, to provide 
                        <E T="03">new</E>
                         customers with health IT certified to revised criteria. Specifically, we have finalized that for health IT developers that obtain new customers after the effective date of a final rule, the health IT developer must provide health IT certified to revised certification criteria either in the timeframe identified in part 170 or not later than 12 months after the purchasing or licensing relationship has been established between the health IT developer and the new customer for the health IT certified to the revised criterion.
                    </P>
                    <P>
                        The timeframe, as noted above, will offer health IT developers no less than 12 months to provide health IT certified to revised certification criteria to new customers (
                        <E T="03">i.e.,</E>
                         customers new to the capability). Based on the timeframe, a health IT developer has the ability to plan both the certification to revised certification criteria and the execution of contracts and agreements with new customers to ensure that it can meet the above timeline for new customers. To note, we have also finalized a conforming revision to the Real World Testing Maintenance of Certification requirements in § 170.405(b), as proposed at 88 FR 23830, in that we removed most of the “update and provide” requirements currently found in § 170.405(b)(3) through (7) and (b)(10) because they will be moot based on the effective date of this final rule (
                        <E T="03">e.g.,</E>
                         many timelines expired on December 31, 2022). Therefore, in § 170.405, we removed and reserved paragraphs (b)(3) through (7) and (b)(10).
                    </P>
                    <HD SOURCE="HD2">E. Real World Testing—Inherited Certified Status</HD>
                    <P>In the ONC Cures Act Final Rule, we finalized requirements in § 170.405(a) that a health IT developer with Health IT Module(s) certified to § 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h) must: successfully test the real world use of the technology for interoperability in the type(s) of setting(s) in which such technology would be marketed. We established in § 170.405(b) that each developer's annual real world testing plan is required to be published by December 15 of a given year and would need to address all of the developer's Health IT Modules certified to criteria listed in § 170.405(a) as of August 31 of that year (85 FR 25769). We also finalized that the annual real world testing plan would pertain to real world testing activities to be conducted in the year following the December 15 plan publication due date, with an annual real world testing results report to be published by March 15 (§ 170.405(b)(2)(ii) of the year following the year in which the real world testing is conducted) (85 FR 25774).</P>
                    <P>
                        Many health IT developers, however, update their Health IT Module(s) on a regular basis, leveraging the flexibility provided through the Program's Inherited Certified Status (ICS) option.
                        <SU>186</SU>
                        <FTREF/>
                         Because of the way that ONC issues certification identifiers, this updating can cause an existing certified Health IT Module to be recognized as new within the Program. All updates to certified health IT must be tracked and recorded to support program integrity and transparency within the Program. When a certified health IT developer leverages ICS for Health IT Modules that have been updated, they receive a new certification date for the newer version of the certified Health IT Module. When an ICS certification is issued, a new certification date is issued by the ONC-ACB to reflect these updates. Regular updating, especially on a frequent basis such as quarterly or semi-annually, creates an anomaly that could result in existing certified Health IT Modules being inadvertently excluded from the real world testing reporting requirements because of those updates.
                    </P>
                    <FTNT>
                        <P>
                            <SU>186</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/policy/public_applicability_of_gap_certification_and_inherited_certified_status.pdf.</E>
                        </P>
                    </FTNT>
                    <P>In order to ensure that all developers test the real world use of their certified health IT, as required, we proposed in the HTI-1 Proposed Rule to eliminate this anomaly by requiring health IT developers to include in their real world testing results report the most recent version of those certified Health IT Module(s) that are updated using Inherited Certified Status after August 31 of the year in which the plan is submitted (88 FR 23831). This approach would ensure that health IT developers fully test all applicable Health IT Modules as part of their real world testing requirements. This policy would also prevent a developer from avoiding, or delaying conducting or reporting, real world testing specifically on the updated versions of Health IT Modules certified through Inherited Certified Status after August 31 of a given year. This policy would not change the underlying requirement that a developer with one or more Health IT Modules certified to any criterion listed in § 170.405(a) must plan, conduct, and report on real world testing of each of those Health IT Modules on an annual basis.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A significant number of commenters supported our proposal to require developers of certified health IT to include in their real world testing results report newer versions of those certified Health IT Module(s) that are updated using Inherited Certified Status after August 31 of the year in which the plan is submitted. Many commenters reiterated the importance of real world testing and expressed appreciation for ONC's efforts to address the anomaly that could result in existing certified Health IT Modules being inadvertently excluded from the real world testing reporting requirements when updated using Inherited Certified Status before their real world testing results reports are due. Several commenters praised the requirement to demonstrate conformity in a production environment and the assurance gained from testing results that reflect the most recent version of the certified health IT used to meet real world testing requirements. A commenter in support of this proposal suggested that ONC make real world testing mandatory for all health IT developers. Overall, commenters in support of this proposal recognize real world testing as a critical component to verifying certified health IT, eligible for real world testing, works in real world scenarios and use cases, and appreciate ONC's efforts to advance real world testing requirements by requiring health IT updated using Inherited Certified Status to be included in health IT developers' real world testing results reports. One commenter requested that ONC clarify in rulemaking which versions of the certified Health IT Module, after updating using ICS, are required to be included in real world testing results report.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments and agree with the need to 
                        <PRTPAGE P="1311"/>
                        ensure newer versions of certified Health IT Modules updated after the August 31 deadline using Inherited Certified Status are accounted for in real world testing and results reporting. We have issued 
                        <E T="03">public resources</E>
                         that provide clarity on what versions of certified health IT should be included in real world testing results reports and believe that the guidance is sufficient for developers to determine, for their unique circumstances, which versions of their certified health IT should be included in their results reports.
                        <SU>187</SU>
                        <FTREF/>
                         Currently, certification criteria identified in § 170.405(a) are required to adhere to the Real World Testing Condition and Maintenance of Certification requirements, and this final rule does not change the applicable criteria (§ 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h)).
                        <SU>188</SU>
                        <FTREF/>
                         ONC will continue to collaborate with interested parties to ensure all required certified health IT continues to function in real-world scenarios and workflows as intended by certification requirements for interoperability and data exchange. We have finalized our requirements at § 170.405(b)(2)(ii) for health IT developers to include in their real world testing results report the newer version of those certified Health IT Module(s) that are updated using Inherited Certified Status after August 31 of the year in which the plan is submitted.
                    </P>
                    <FTNT>
                        <P>
                            <SU>187</SU>
                             See Real World Testing Resource Guide and other resources at: 
                            <E T="03">https://www.healthit.gov/topic/certification-ehrs/real-world-testing.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>188</SU>
                             Please see the Real World Testing Fact Sheet, page 3, for a list of certification criteria at: 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2021-02/Real-World-Testing-Fact-Sheet.pdf#page=3.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter was not supportive of this proposal and the requirement for health IT developers to conduct real world testing on their certified health IT and expressed concerns that it adds no value to health IT certification. This commenter suggested that if available functionality is not being implemented in production environments it should not be required for real world testing.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We did not propose any substantive changes or updates to the real world testing requirements in § 170.405. Congress required the real world testing of certified health IT for interoperability in the Cures Act (PHSA § 3001(c)(5)(D)(v)). We have implemented this requirement through the Real World Testing Condition and Maintenance of Certification requirements. The real world testing of certified health IT has value to the Program and users of certified health IT. Since December 2022, more than 500 real world testing plans and results have been submitted by developers of certified health IT with applicable certification criteria. The plans and reports have provided insight into how developers of certified health IT think about framing and measuring the interoperability of their certified Health IT Modules in production use. The plans and reports also provide interested parties with information they can use to understand how a specific certified Health IT Module is demonstrating real world interoperability.
                        <SU>189</SU>
                        <FTREF/>
                         We are aware of the challenges faced by health IT developers when establishing approaches to meet their real world testing requirements. ONC has released several public resources to assist the developer community in developing real world testing plans and navigating unique circumstances such as low adoption of specific certified health IT capabilities.
                        <SU>190</SU>
                        <FTREF/>
                         Among numerous points of guidance, the Real World Testing Resource Guide includes information on how developers of certified health IT should treat Health IT Modules that do not have functionality or that have not yet implemented functionality in production environments. We also reiterate that the Aug 31 deadline for eligible certified health IT supports developer preparation activities well before entering the applicable calendar year of real world testing.
                    </P>
                    <FTNT>
                        <P>
                            <SU>189</SU>
                             
                            <E T="03">https://chpl.healthit.gov/#/collections/real-world-testing.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>190</SU>
                             See Real World Testing Resource Guide and other resources at: 
                            <E T="03">https://www.healthit.gov/topic/certification-ehrs/real-world-testing.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters raised concerns that are out of scope for the proposal, including suggestions for additional certification and real world testing requirements to improve interoperability, none of which are addressed in this rulemaking. Some made recommendations for how ONC may enhance certification and real world testing requirements by further defining measures, data elements, and how health IT should be assessed for data augmentation solutions. A number of these commenters expressed the need for additional real world testing requirements, such as more rigorous testing of data segmentation, standards and implementation guides, and required standard code sets. Some commenters requested more focus on public health data and the use of standard code sets to improve data quality for real world testing, stating that clinical and laboratory partners require data inputs that are high quality, correctly coded, and not reliant on human readability or narrative text to provide critical information. Commenters asserted that these additions to real world testing requirements would diminish mapping burden, improve data entry, facilitate improvements to data quality, and lessen administrative burden on clinical staff. One commenter requested that ONC require real world testing of certified health IT before the sale and implementation of the certified health IT in clinical settings. Another commenter requested that ONC not consider standards mature until they have been real world tested with publicly available comprehensive testing reports. Lastly, one commenter raised issues related to human research protocols when conducting real world testing using real patient data and the need to protect this data from misuse.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the input. Because these recommendations for certification and real world testing requirements are out of scope for the HTI-1 Proposed Rule in that we did not propose to change any related real world testing conformance requirements, we decline to finalize any such changes. ONC previously finalized requirements, through the ONC Cures Act Final Rule, for real world testing plans and results reports, the required elements to be included, and developers' responsibilities for establishing measure(s) for their approach to assessing their health IT in real world settings (see 85 FR 3580). We reiterate that the proposal finalized in this final rule specifically addresses health IT developers who update their certified Health IT Modules using Inherited Certified Status after the August 31 deadline and before results reports are due for a particular year of real world testing. We also note that the Inherited Certified Status flexibility is specifically designed for updates to certified Health IT Modules that do not adversely impact certified capabilities.
                    </P>
                    <HD SOURCE="HD2">F. Insights Condition and Maintenance of Certification</HD>
                    <HD SOURCE="HD3">1. Background and Purpose</HD>
                    <P>
                        The Cures Act specified requirements in section 4002(c) to establish an EHR Reporting Program to provide reporting on certified health IT in the categories of interoperability, usability and user-centered design, security, conformance to certification testing, and other categories, as appropriate to measure the performance of EHR technology. Data collected and reported would address information gaps in the health IT marketplace and provide insights on the use of certified health IT.
                        <PRTPAGE P="1312"/>
                    </P>
                    <P>To develop the EHR Reporting Program, ONC contracted with the Urban Institute and its subcontractor, HealthTech Solutions, to engage the health IT community for the purpose of identifying measures that developers of certified health IT would be required to report on as a Condition and Maintenance of Certification under the Program. Detailed background and history on the overall process, and the Urban Institute's reports, can be found in the April 18, 2023 Proposed Rule titled, “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” (88 FR 23832). For clarity purposes, we refer to the Condition and Maintenance of Certification associated with the “EHR Reporting Program” as the “Insights Condition and Maintenance of Certification” (also referred to as the “Insights Condition”) throughout this final rule. We believe this descriptive name captures a primary policy outcome of this requirement.</P>
                    <HD SOURCE="HD3">2. Insights Condition and Maintenance of Certification—Final Measures</HD>
                    <P>
                        In the HTI-1 Proposed Rule (88 FR 23831), we stated that the proposed measures associated with the Insights Condition related to and reflected the interoperability category in section 3009A(a)(3)(A)(iii) of the PHSA. We further stated that these measures related to four aspects or areas of interoperability, which we referred to as measurement “areas:” individuals' access to EHI, public health information exchange, clinical care information exchange, and standards adoption and conformance, as discussed in further detail below (88 FR 23831). We explained that the majority of our proposed measures were data points derived from certified health IT. The measures generally consisted of numerators and denominators that would help generate metrics (
                        <E T="03">e.g.,</E>
                         percent across a population), which were further detailed in each measure, but the measures could also serve as standalone values. We noted that in some cases we planned to generate multiple metrics by using different denominators for the same numerator or using different numerators with the same denominator. For each proposed measure, we included information on the rationale for the proposed measure, proposed numerators and denominators, and key topics for comment.
                    </P>
                    <P>
                        As stated in the HTI-1 Proposed Rule, we proposed to modify measures developed by the Urban Institute to reduce ambiguities and to address potential costs and burdens. Based upon public comment and interested party input consistent with section 3009A(a)(3)(C) and (D) of the PHSA, we proposed to modify the measures the Urban Institute developed, as well as the proposed minimum reporting qualifications, to ensure that small and startup developers are not unduly disadvantaged by the measures.
                        <SU>191</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>191</SU>
                             Urban Institute. See 
                            <E T="03">https://www.urban.org/policy-centers/health-policy-center/projects/ehr-reporting-program.</E>
                        </P>
                    </FTNT>
                    <P>We also stated that in future rulemaking we anticipated proposing additional measures for future iterations of the Insights Conditions and Maintenance of Certification requirements under the Program and that through this first set of measures we intended to provide insights on the interoperability category specified in the Cures Act (as codified at section 3009A(a)(3)(A)(iii) of the PHSA). We also stated that we intended to explore the other Cures Act categories (security, usability and user-centered design, conformance to certification testing, and other categories to measure the performance of EHR technology) in future requirements (88 FR 23832).</P>
                    <P>
                        In the HTI-1 Proposed Rule (88 FR 23832), we stated that we explored various pathways on how to make it easier for the public to view and comment on the detailed technical specifications supporting the measures. We directed readers to consult our website 
                        <E T="03">healthIT.gov</E>
                         and provide comment on the technical specifications for measure calculation. We received numerous comments regarding the information described in the technical specifications for the measures, including the definitions of various measurement-related terms such as encounters and duplicate C-CDAs. We have included summaries of these comments within their respective measure sections in this final rule. While the substantive requirements for each measure are defined in this final rule, we determined that measure specification sheets are a logical and accessible method for the public to also view the technical specifications that support those requirements. The finalized specification sheets accompanying this final rule are available at 
                        <E T="03">www.healthit.gov/hti-1.</E>
                         This is consistent with the approach used by other HHS programs related to measure technical specifications (
                        <E T="03">e.g.,</E>
                         CMS Electronic Clinical Quality Measures (CMS eCQMs)).
                        <E T="51">192 193</E>
                        <FTREF/>
                         This approach of publishing technical specification separately allows for more effective viewing of the technical details, including supporting public comment on those specifications in a transparent manner. We welcomed comments on the measure specifications sheets accompanying the HTI-1 Proposed Rule and noted in the HTI-1 Proposed Rule (88 FR 23832) that such public comment will be used to further refine the technical specifications. We also stated that we intended to keep these measure specification sheets up to date. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion.
                    </P>
                    <FTNT>
                        <P>
                            <SU>192</SU>
                             
                            <E T="03">https://ecqi.healthit.gov/.</E>
                        </P>
                        <P>
                            <SU>193</SU>
                             
                            <E T="03">https://mmshub.cms.gov/get-involved/public-comments/overview.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters, including health care provider specialty organizations, technology advocates, health information exchanges, healthcare quality organizations, and some health IT developers, were generally supportive of our proposals to implement the new Insights Condition, and of the measures and reporting processes described. A few commenters emphasized the potential of information gleaned from the Insights Condition to drive transparency in the health IT marketplace and, in particular, to highlight ways for patients to access and use their data. One commenter noted that ONC's development of the Insights Condition demonstrates commitment to improving interoperability, and encouraged ONC to envision a future state of health information exchange capabilities that include patient-requested restrictions, outcomes tracking, and integration of data from other sources such as Prescription Drug Monitoring Programs. Commenters also lauded the potential of the Insights Condition to clarify trends in current capabilities for interoperability services such as APIs that will allow the market to address gaps and improve interoperability. One commenter noted that they believe public health programs and safety net providers could particularly benefit from the Insights Condition and encouraged ONC to work with community health centers to ensure that its implementation supports the populations they serve.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the feedback and appreciate their support for the potential of the Insights Condition to address information gaps in the marketplace and improve interoperability. We also appreciate comments taking note of our efforts to improve interoperability and continue to explore avenues to increase efficient information exchange for use in improving health and healthcare. As 
                        <PRTPAGE P="1313"/>
                        stated in the HTI-1 Proposed Rule (88 FR 23831), data collected and reported under the Insights Condition will address information gaps in the health IT marketplace and provide insights on the use of certified health IT. We also agree that public health and safety net providers can benefit from increased market transparency that the Insights Condition can provide. We will continue to engage with public health professionals and safety net providers in our implementation of the Program.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters suggested that information gained from the Insights Condition will not benefit current users of certified health IT, and some commenters questioned the value of the data in furthering interoperability.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We fundamentally disagree with this perspective offered by some commenters. In the Cures Act, Congress established the requirement to create an EHR Reporting Program and we believe that submission of specific measures pursuant to the Insights Condition under the Program will provide transparent reporting, address information gaps in the health IT marketplace, and provide insights on the use of certified health IT. The adopted metrics are specifically meant to provide insights on how certified health IT enables various aspects of interoperability, including individuals' access to EHI, public health information exchange, clinical care information exchange, and standards adoption and conformance. These metrics help address gaps in information in the health IT marketplace by providing data on key aspects of interoperability that are neither directly nor publicly available from other sources. As described in greater detail within this final rule, the metrics will be shared with the public in a transparent manner on ONC's website.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters expressed support and understanding of the use of numerators and denominators by ONC. One professional society expressed support of all proposed measures and numerator/denominator combinations. One commenter specifically voiced support for all the various numerator/denominator combinations proposed as a key opportunity to provide market transparency on various aspects of how information is being exchanged and used by patients and health care providers, and another commenter specifically supported requiring health IT developers to report on the measures. Further, the commenter highlighted the potential of the various combinations to help ONC provide market transparency on various aspects of how information is being exchanged and used by patients and health care providers.
                    </P>
                    <P>On the other hand, a number of commenters expressed confusion related to the terms numerator and denominator. One commenter requested ONC establish more succinct separation and definition of numerators and denominators for the Insights Condition. Further, the commenter stated measure definitions for numerators and denominators are confusing and overlap. Another commenter found the terms numerator and denominator confusing and requested that ONC use different ones. One commenter encouraged ONC to maximize reuse of collected data, such as allowing a given measure to be submitted once and tagged to count for all relevant metrics where it can be reused. One commenter suggested that ONC state in the overview section for the Insights Condition that developers will be required to submit raw data, and metrics will be calculated after submission. Another commenter suggested removing expected metrics from the specification sheets and only focusing on counts or metrics to be collected by health IT developers.</P>
                    <P>
                        <E T="03">Response.</E>
                         To reduce confusion, we have replaced the terms “numerator” and “denominator” with “metric” throughout the Insights Condition. Numerator and denominator were terms meant to identify how the metrics would be used to generate various statistics, but given the confusion expressed through public comments related to these terms, we have simplified and replaced these terms. Thus, instead of a list of numerators and denominators that would be submitted, health IT developers shall be responsible for submitting a list of metrics. This applies across all the finalized measures. This represents a change in terminology and does not represent a substantive change. Developers of certified health IT are responsible for reporting on the metrics, not calculating the derived statistics. We would like to reiterate that ONC will be responsible for calculating any derived statistics from the reported metrics using various combinations of the metrics (previously known as numerators and denominators). In other words, this final rule focuses on listing the metrics that developers of certified health IT would be collecting and reporting, rather than the derived statistics which ONC will calculate.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters requested clarification on the information that would be required for submission by health IT developers. One commenter requested ONC establish detailed, clear, and consistent specifications for reporting and attestation under the Insights Condition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As stated earlier in this preamble and in the HTI-1 Proposed Rule (88 FR 23832), we explored various pathways on how to make it easier for the public to view the detailed technical specifications supporting the measures. We determined that measure specification sheets were a logical and accessible method for the public to view the technical specifications supporting those requirements in a clear and consistent manner and that measure specification sheets have been used successfully by other agencies such as CMS for detailing their measures. The information in this preamble and in the measure specification sheets provides the list of metrics and specifications for reporting and attestation under the Insights Condition. We intend to provide up to date measure specification sheets to assist with the community's understanding of the finalized measures and metric calculations. The measure specifications provide granular definitions and other information needed to operationalize the metrics to ensure they are implemented in a consistent manner across health IT developers. The updated measure specification sheets that reflect the final set of metrics will be available for download and viewing on ONC's website at 
                        <E T="03">www.healthit.gov/hti-1.</E>
                         We believe that the measure specification sheets provide a more user-friendly format that is more easily accessible. For example, given that not all metrics may be applicable to all health IT developers, developers can select which metrics they wish to review and download. We also intend to publish educational materials on ONC's website that include graphics and other visual displays to help explain the metrics and the reporting process.
                    </P>
                    <HD SOURCE="HD3">Measurement Area: Individual Access to Electronic Health Information</HD>
                    <P>In the HTI-1 Proposed Rule, we proposed in § 170.407(a)(1) a measure within the individuals' access to their EHI measurement area to require that any developer of certified health IT with Health IT Modules certified to the criteria specified in the measure to report on the different methods individuals use to access their health information. We refer readers to the HTI-1 Proposed Rule (88 FR 23833) for detailed background associated with the “individuals' access to electronic health information supported by certified API technology” measure.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters expressed support for the proposed 
                        <PRTPAGE P="1314"/>
                        measure noting the importance of patients' engagement in their own healthcare and the need to further understand how individuals access their health data. Most commenters indicated support of the general intent and focal points of the proposed measure, while including recommendations to simplify the measure. Some commenters indicated this measure would pose a high level of burden, particularly related to encounter-based metrics. Another commenter stated the proposed measure should not present a significant regulatory burden as the data can be collected in real-time using established technologies.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have made revisions in response to public comment in an effort to reduce burden and simplify reporting as further described below. We note for readers that we have revised some of the measure names (including the name of this measure, which we updated to individuals' access to electronic health information through certified health IT) for additional clarity and consistency. The revisions to the measure names do not inherently reflect substantive changes to the measure. We have used the phrase “certified health IT” across our measures to provide clarity and consistency across the Program. We thank commenters for expressing support for the proposed measure and agree that it will contribute valuable insight into the methods that individuals use to obtain access to their EHI. This information can help ONC and others build an understanding of where EHI is available for usage so that individuals can make informed decisions about their healthcare.
                    </P>
                    <HD SOURCE="HD3">Individuals' Access to Electronic Health Information Through Certified Health IT Measure</HD>
                    <P>We proposed (88 FR 23833) to adopt the “individuals' access to electronic health information supported by certified API technology” measure within the “individuals' access to electronic health information” area in sect; 170.407(a)(1). We proposed (88 FR 23833 and 23834) to require that any developer of certified health IT with Health IT Modules certified to either the “view, download, and transmit to a 3rd party” certification criterion (§ 170.315(e)(1)), or the “standardized API for patient and population services” certification criterion (§ 170.315(g)(10)), report the numbers of unique patients that used each of the specified methods to access their EHI.</P>
                    <P>We proposed two distinct numerators and three denominators as part of the measure (88 FR 23834) in § 170.407(a)(1) and noted that we planned to generate multiple metrics from a combination of different numerators and denominators. We proposed (88 FR 23834) the first numerator to be the number of unique individuals who had an encounter and accessed their EHI at least once during the reporting period via at least one of three types of methods: (1) third-party app using technology certified to “standardized API for patient population services” certification criterion under § 170.315(g)(10); (2) patient portal using technology certified to the “view, download, and transmit to 3rd party” certification criterion under § 170.315(e)(1) only; or (3) app offered by the health IT developer or health care provider using technology certified to the API criterion under § 170.315(g)(10) (if applicable). We proposed (88 FR 23834) a second numerator to be the number of unique individuals who accessed their EHI regardless of an encounter during the reporting period using at least one of the same three types of methods identified above. We stated that each of these numerators would be stratified or reported by type of method. For detailed background on the proposed measure, we refer readers to the HTI-1 Proposed Rule (88 FR 23834).</P>
                    <P>We proposed (88 FR 23834) the first denominator for this measure to be the total number of unique individuals who had an encounter during the reporting period. We proposed (88 FR 23834) the second denominator to be the total number of unique individuals who used at least one of the types of methods referenced above to access their EHI who had an encounter during the reporting period. We proposed (88 FR 23834) the third denominator to be the total number of unique individuals who used at least one of the three types of methods referenced above to access their EHI during the reporting period (regardless of whether the individual had an encounter or not).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters representing EHR developers stated that the proposed measure would result in medium to high qualitative ratings of burden, particularly for the encounter-based measures, and shared suggestions to modify its structure. Several commenters representing health IT developers recommended separating the measure into two measures: (1) a measure applicable to Health IT Modules certified to the § 170.315(g)(10) criterion; and (2) a measure applicable to Health IT Modules certified to the § 170.315(e)(1) criterion. These commenters also expressed concern that the structure of the measure did not align with product level reporting and could create issues and inconsistencies in reporting and interpreting its results. These commenters further stated that many Health IT Modules are certified either to § 170.315(g)(10) or 170.315(e)(1), but very few are certified to both. They suggested that ONC revise the measure to report on patient access (view, download, and transmit) via patient portal versus FHIR via apps and reported at the developer level.
                    </P>
                    <P>Commenters also recommended removing the third access method that was proposed in the HTI-1 Proposed Rule (88 FR 23834) referred to as “App offered by the health IT developer or health care provider using technology certified to the API criterion under § 170.315(g)(10) (if applicable).” They explained that, per the API Condition and Maintenance of Certification requirements, developers of certified Health IT Modules shall treat all (similarly situated) app developers as the same. Therefore, they would be unable to distinguish whether an app is offered by a developer of certified health IT or by a health care provider. Two commenters stated that they would be able to distinguish between access via apps that they developed versus others, but they did not see the relevance of it.</P>
                    <P>Commenters also requested clarification on the measure structure for numerators and denominators.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the assessment from commenters on the level of effort to develop this measure. Considering the medium to high burden ratings from health IT developers that commented on the measure, we have made three modifications intended to simplify and reduce the burden of implementing the measure while establishing a starting place for initial reporting that can be expanded in the future.
                    </P>
                    <P>
                        First, given that commenters indicated that it would be difficult to distinguish whether an app is offered by a developer of certified health IT or by a health care provider, we have removed the third method of access to EHI from the measure that we had proposed in the HTI-1 Proposed Rule (88 FR 23843), referred to as, “App offered by the health IT developer or health care provider using technology certified to the API criterion under § 170.315(g)(10) (if applicable).” Second, we have simplified the metrics (formerly referred to as numerators and denominators) by removing the stratification related to methods of access, and instead incorporated the stratification in the metrics. This now aligns the metrics to each associated criterion and addresses the concern that very few Health IT Modules are certified to both criteria 
                        <PRTPAGE P="1315"/>
                        (§ 170.315(g)(10) or § 170.315(e)(1)). Third, as suggested by commenters, we have removed the metrics related to encounters from this measure. We acknowledge that health IT certified to one criterion only, particularly to § 170.315(g)(10), would not be able to report encounters. By removing the requirement around unique individuals with encounters, we expect that developers of products certified to only one criterion will be able to report access to EHI via the applicable method. We also finalized this measure without encounter-based metrics as we considered how an encounter-based measure would apply to health IT developers who offer and implement integrated systems across ambulatory and inpatient settings, as well as developers who offer and implement only ambulatory systems and only inpatient systems. For developers offering integrated systems, an individual might have an ambulatory visit and an inpatient visit within the reporting period and access their EHI. However, the proposed construction of the encounter-based metrics would have required developers to determine the unique individuals and reconcile their encounters and EHI access across ambulatory and inpatient value sets, which would be a complex endeavor. Therefore, this measure does not include encounter-based metrics in efforts to reduce both complexity and burden of implementing the measure.
                    </P>
                    <P>We will use a third metric, which counts the number of unique individuals who access their EHI during the reporting period using any method, to assess trends in individuals' use of the two methods of access. This will allow ONC to evaluate as developers of certified health IT continue to make more APIs available under § 170.315(g)(10), and it will also provide insight into individuals' use of methods beyond those required for certification that are facilitating patient access to their electronic health information.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter requested clarification on whether individuals were expected to have both an encounter during the reporting period and access their EHI during the reporting period, or whether the reporting period refers only to the encounter. The commenter also requested clarification on whether the individual has ever accessed their EHI should be counted. A couple of commenters expressed concern about whether deduplication is expected, noting that most denominators and numerators are feasible if developers of certified Health IT Modules are not expected to deduplicate individuals' access counts. They suggested ONC should either change counts to be transaction-based and avoid unique patient measurement, or clarify that unique patient count will be unique only within each instance of the EHR software and cannot be deduplicated across instances.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have revised the encounter-based approach for the measure so that encounters are no longer included. With regards to the concern related to deduplication, we require unique patient counts of access during the reporting period. However, we recognize that the counts would only be unique within each instance of the EHR software. To clarify, the measure should report on whether individuals accessed their data during the reporting period; this is not a measure of an individual ever accessing their EHI.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested that ONC clearly state whether the scope is for patients accessing their own records, exclusive of authorized representative access events. Most commenters requested that the measure not include access by authorized representatives. One commenter requested that ONC should include access by an individual's authorized representative in the measure count.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback on whether patient-authorized representatives should count in the measure when they access EHI and note that there was no consensus. While we agree with the commenter suggesting that ONC should include access by an individual's authorized representative, we did not propose this distinction for our measure. As such, we may incorporate patient-authorized representatives in future rulemaking, noting that it would be beneficial to align this measure with the CMS Promoting Interoperability (PI) Measure for patient access, which similarly counts patients and their authorized representative in the numerator for providing access to patient-authorized representatives for view, download, and transmit (VDT), and apps of the patients' choice.
                        <SU>194</SU>
                        <FTREF/>
                         The finalized measure only counts individuals.
                    </P>
                    <FTNT>
                        <P>
                            <SU>194</SU>
                             CMS. 2022 MEDICARE PROMOTING INTEROPERABILITY PROGRAM FOR ELIGIBLE HOSPITALS AND CRITICAL ACCESS HOSPITALS. Provider to Patient Exchange Objective Fact Sheet 
                            <E T="03">https://www.cms.gov/files/document/2022-provider-patient-exchange-objective-fact-sheet.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments indicating the need to clarify the definition for access to EHI. Some commenters sought further clarification on the proposed methods of portal and API access for this measure. One commenter asked, in cases where the patient portal may display several electronic health information elements on the log-in landing page, if such a scenario counts as a patient accessing their EHI via a patient portal. One commenter asked whether patient portal access should count any use of the patient portal or specifically a view, download, or transmit to a 3rd party activity. Regarding individual access via a developer's app, a commenter requested clarity on whether an app using different technology than what is included in § 170.315(g)(10) should be counted. For an API, one commenter requested clarity on whether the measure should record the submission of a request for information or the response to the request.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the opportunity to clarify how access to EHI is defined for the finalized measure. The definitions associated with this measure (as noted earlier) are described in detail in the measure specifications. Access to EHI via patient portal using technology certified to the “view, download, and transmit to 3rd party” certification criterion under § 170.315(e)(1) is counted as a patient log-in with the access credential belonging to the individual at least once during the reporting period. Access to EHI via technology certified to the “standardized API for patient population services” certification criterion under § 170.315(g)(10) is counted as the individual's authorization, as indicated by an access token, at least once during the reporting period. To summarize, access to EHI is based upon an individual logging into a system (whether that be a portal or third-party app or other system) within the reporting period and is not based on accessing any specific piece of information or performing any specific action within the system itself such as view, download and transmit activities.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received some comments suggesting expanding the proposed measure. One commenter suggested that the data should report on whether individuals are accessing their health information more than once in the same reporting period. Another suggested that the data should report those individuals who tried to access their health information via the proposed methods and failed. Another commenter suggested reporting “percentage of use” similar to what was proposed for the “use of FHIR bulk data access through certified health IT” measure to measure the adoption of API-based means of access by single users in a developer's client base. One commenter noted that the most common 
                        <PRTPAGE P="1316"/>
                        method for authenticating users of third-party health apps is via their patient portal account and that some patients may only use their portal to access their app of choice. They suggested ONC provide an additional metric to determine whether the portal is being used to access health information directly or to access health information via a third-party app. Finally, one commenter suggested collecting additional data for this measure to support health equity, suggesting the measure include a patient's language.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate comments suggesting expanding the measurement of individual access to EHI and agree that there are several important dimensions of access to EHI to explore. Given that we also received numerous comments related to the burden associated with reporting the current proposed measures, we have not added the suggested additional requirements at this time, though they may provide further insights. Our intent is to balance the value of the information we now require to be collected with the burden of doing so. We may consider these suggestions in future iterations of the measure through rulemaking.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern and requested clarification about how the measure may reflect on the quality of a developer of certified Health IT Modules' products. The commenter stated that health care providers have the relationships with patients and provide the instructions to access their health information, while developers have no influence on these activities.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We acknowledge that there are many factors that influence how and to what degree individuals access their EHI, including those mentioned by commenters. While the results do not solely reflect on the performance of the health IT developers, the methods health IT developers provide to access EHI may vary in usability, implementation of functionality, and robustness of functionality, which may influence patient and provider use of EHI. The measure intends to shed light on the role that health IT plays in facilitating access to EHI through different methods.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter asked about the entity that would be responsible for reporting on the measure in a situation where the health IT developer relies upon a different certified Health IT Module (owned by a separate entity) in order to meet the certification criteria associated with the Insights Condition (in this case § 170.315(e)(1). Specifically, the commenter sought clarity on whether the developer of the certified health IT module using the relied upon software would be responsible for reporting, or if the developer of that relied upon software would be responsible for reporting.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the request for clarification. In these instances, similar to how this is addressed through the Real World Testing requirements,
                        <SU>195</SU>
                        <FTREF/>
                         we would expect a health IT developer using relied upon software in its Health IT Module to meet the certification requirement associated with § 170.315(e)(1) to report on this Insights Condition measure on its own accord. The health IT developer may work with its relied upon software vendor, if necessary, to report on the metrics.
                    </P>
                    <FTNT>
                        <P>
                            <SU>195</SU>
                             ONC Health IT Certification Program. Real World Testing Guide. (Last updated: May 23, 2023). See p. 18. 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2021-08/ONC-Real%20World%20Testing%20Resource%20Guide_Aug%202021.pdf.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Finalization of Measure</HD>
                    <P>
                        We have finalized the measure as “individuals' access to electronic health information through certified health IT
                        <E T="03">”</E>
                         in § 170.407(a)(3)(i). We have revised the proposed measure based on public comments received. Specific metrics to support this finalized measure are listed below and described further in the accompanying measure specification sheets located on ONC's website. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion. The reporting period for the measure and related metrics below consists of one calendar year. Data collection for the measures and associated metrics will begin during the first phase of reporting (which is described later in the preamble):
                    </P>
                    <P>(1) Number of unique individuals who accessed their EHI during the reporting period using technology certified to the “standardized API for patient population services” certification criterion under § 170.315(g)(10).</P>
                    <P>(2) Number of unique individuals who accessed their EHI during the reporting period using technology certified to the “view, download, and transmit to 3rd party” certification criterion under § 170.315(e)(1).</P>
                    <P>(3) Number of unique individuals who accessed their EHI using any method. The methods are not limited to third-party apps using technology certified to “standardized API for patient population services” certification criterion under § 170.315(g)(10) or patient portals using technology certified to the “view, download, and transmit to 3rd party” certification criterion under § 170.315(e)(1) during the reporting period.</P>
                    <HD SOURCE="HD3">Measurement Area: Clinical Care Information Exchange</HD>
                    <P>In HTI-1 Proposed Rule (88 FR 23834), we proposed two measures under the “clinical care information exchange” area in § 170.407(a)(2) and (3) titled, “C-CDA documents obtained using certified health IT by exchange mechanism” and “C-CDA medications, allergies, and problems reconciliation and incorporation using certified health IT.” These measures primarily focused on characterizing the state of information exchange between health care providers who are customers of health IT developers with certified health IT, in contrast to other measures that capture exchange with individuals, public health agencies, and other entities.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Numerous commenters indicated general support for both clinical care information exchange measures. Commenters representing health care providers valued the reconciliation and incorporation measure because effective reconciliation and incorporation of medication, allergy, and problem information through certified health IT benefits patient safety and care coordination. Some commenters suggested that examining volume alone would not be a good indicator of interoperability advancement or quality. Rather, measures that focus on the efficiency of reconciliation in combination with volume measures would provide better insights into the advancements in interoperability. One commenter suggested removal of both measures.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support expressed for both clinical care exchange measures. We believe measuring volume is important as it provides the means to assess the extent that patient information is moving between providers to facilitate high value care. Furthermore, patient and encounter volume measures help contextualize and interpret other measures designed to assess progress related to interoperability. Current measures to understand the magnitude of information exchange and use are fundamentally limited. For example, as noted in the HTI-1 Proposed Rule (88 FR 23835), publicly available information from some health information networks can be difficult to interpret without also knowing the 
                        <PRTPAGE P="1317"/>
                        number of encounters occurring at sites using these methods, the number of patients being treated, and other measures of volume. Measures intended to provide insight into the volume of information exchanged across the nation are not feasible to collect from end users through clinical surveys, and the CMS PI Program measure is reported by a subset of providers that participate in that program.
                    </P>
                    <P>We agree with commenters that measures of efficiency and effectiveness of health IT to support deduplication and reconciliation alongside measures of volume of clinical care documents received and incorporated will provide valuable insight on interoperability trends. Both measures are discussed more fully below.</P>
                    <HD SOURCE="HD3">Consolidated Clinical Document Architecture (C-CDA) Documents Obtained Using Certified Health IT by Exchange Mechanism Measure</HD>
                    <P>We proposed (88 FR 23834 and 23835) to adopt the “C-CDA documents obtained using certified health IT by exchange mechanism” measure in § 170.407(a)(2). We stated that this measure would report on the volume of C-CDA documents obtained using certified health IT by exchange mechanism relative to patient volume, and that a developer of certified health IT with Health IT Modules certified to the “clinical information reconciliation and incorporation” certification criterion in § 170.315(b)(2) would be required to report the proposed numerators and denominators for this measure. We refer readers to the HTI-1 Proposed Rule (88 FR 23834 through 23836) for detailed background on the proposed measure.</P>
                    <P>
                        We proposed four numerators and four denominators for this measure (88 FR 23835). We noted in the HTI-1 Proposed Rule (88 FR 23835 and 23836) that we planned to generate multiple metrics from different combinations of these numerators and denominators. We proposed to adopt the following numerators for this measure: (1) number of unique C-CDA documents obtained (which we defined for the purpose of this proposal as either C-CDAs that are received—that is, C-CDAs that have been sent or `pushed' by others and received using certified health IT or C-CDAs that are queried—that is, C-CDAs that were found or `pulled' from a network or central repository using certified health IT) using certified health IT and Direct Messaging during the reporting period; (2) number of unique C-CDA documents obtained (received or queried) using certified health IT and a local/regional health information exchange (HIE) or national health information network (HIN) during the reporting period; (3) number of unique C-CDA documents obtained (received or queried) using certified health IT and a developer-specific HIN (
                        <E T="03">i.e.,</E>
                         a network that facilitates exchange between entities using the same health IT developer's products) during the reporting period; and (4) number of unique C-CDA documents obtained (received or queried) using certified health IT and a method not listed above and not including electronic fax during the reporting period.
                    </P>
                    <P>
                        We proposed (88 FR 23835) to adopt the following denominators for this measure: (1) number of encounters during the reporting period; (2) number of unique patients with an encounter during the reporting period; (3) number of unique patients with an associated C-CDA document during the reporting period; and (4) number of unique C-CDA documents obtained (received or queried) using certified health IT during the reporting period. We proposed (88 FR 23835) to include denominators for the number of encounters during the reporting period and the number of unique patients seen (
                        <E T="03">i.e.,</E>
                         with an encounter) during the reporting period to provide a sense of the volume of C-CDA documents exchanged relative to the number of instances when a C-CDA document might be useful.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         While numerous commenters expressed general support for this measure, some commenters raised concerns. Their major concerns related to: (1) burden associated with the measure and the overall program; potentially including health care providers as they may need to map their exchange partners to different types of networks for reporting purposes; (2) rethinking the mechanisms which include a mix of methods and standards that are not mutually exclusive; (3) measuring beyond standards that reflect the current state such as FHIR, which may become dominant in the future; (4) better defining and specifying the selected exchange mechanisms; and (5) potentially including mechanisms that do not result in structured, interoperable data, such as e-fax, to more fully measure the totality of exchange, including exchange across the care continuum with providers who do not possess electronic exchange capabilities.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback and agree with the concerns raised by commenters related to the potential burden of some metrics, including impacts on providers, the need to reduce overall burden associated with the Insights Condition, and the ability to meaningfully distinguish between the proposed exchange mechanisms given the overlap between the use of standards and methods of exchange. Therefore, we have not finalized the “C-CDA documents obtained using certified health IT by exchange mechanism” measure. Although we value measuring exchange mechanisms, the ecosystem for HIE methods is evolving, particularly with the launch of TEFCA. The evolving landscape for exchange calls for a measure that tracks trends related to the adoption and use of each mode of exchange to better inform ONC's policy making and health care providers' operational decisions. We may consider proposing a revised version of this measure in a future rulemaking with the intent of capturing trends in how clinical information is being exchanged, inclusive of FHIR-based exchange.
                    </P>
                    <HD SOURCE="HD3">Consolidated Clinical Document Architecture (C-CDA) Problems, Medications, and Allergies Reconciliation and Incorporation Through Certified Health IT Measure</HD>
                    <P>We proposed (88 FR 23836) to adopt the “C-CDA medications, allergies, and problems reconciliation and incorporation using certified health IT” measure in § 170.407(a)(3), which would capture the number of C-CDA documents that are reconciled and incorporated (as defined in § 170.315(b)(2)(iii)) as part of a patient's record by clinicians or their delegates. We proposed (88 FR 23836) that a developer of certified health IT with Health IT Modules certified to the “clinical information reconciliation and incorporation” certification criterion in § 170.315(b)(2) would be required to provide information on how data in C-CDA documents are used, focusing on the reconciliation and incorporation of medications, allergies and intolerances, and problems.</P>
                    <P>We proposed (88 FR 23836) the numerator to be the total number of C-CDA documents of the Continuity of Care Document (CCD), Referral Note, Discharge Summary document types that are obtained and incorporated across all exchange mechanisms supported by the certified health IT during the reporting period. The numerator would increment, or increase in number, upon completion of clinical information reconciliation of the C-CDA documents for medications, allergies and intolerances, and problems, as described in the certification criterion in § 170.315(b)(2).</P>
                    <P>
                        We proposed (88 FR 23836) the denominators for this measure, using 
                        <PRTPAGE P="1318"/>
                        the definition of “encounter” described earlier in the preamble of the HTI-1 Proposed Rule (88 FR 23832), as the following: (1) number of encounters during the reporting period; (2) number of unique patients with an encounter during the reporting period; (3) number of unique patients with an associated C-CDA document during the reporting period; and (4) number of unique C-CDA documents obtained using certified health IT during the reporting period. For this fourth denominator, we indicated that we were aware that in the current landscape, some clinicians and hospitals are able to receive C-CDA documents through multiple methods and it is possible to receive multiple copies of the same C-CDA (
                        <E T="03">e.g.,</E>
                         via Direct Messaging and an HIE). We sought to only include unique C-CDA documents in both the numerator and denominator because we believed that clinicians were unlikely to reconcile multiple copies of the same C-CDA and that by eliminating these duplicates, we would avoid undercounting reconciliation (88 FR 23837).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters who indicated general support for the measure also expressed concerns about the burden associated with the measure. These commenters noted that their reports for clients on a similar measure for the CMS PI Program do not necessarily create efficiencies in aggregating the data across their clients. One commenter indicated the value of the measure did not outweigh the burden because many of their clients do not regularly reconcile and incorporate documents they obtained.
                    </P>
                    <P>
                        Commenters representing EHR developers also provided qualitative ratings of burden associated with these measures. They indicated that the data points (
                        <E T="03">e.g.,</E>
                         numerators/denominators) “number of encounters” and “number of unique patients with an encounter” would be low level of effort; whereas “number of unique patients with an associated C-CDA document” and “number of C-CDA documents of the Continuity of Care Document (CCD), Referral Note, Discharge Summary document types that are obtained and incorporated across all exchange mechanisms” would be a high level of effort. The rest of the clinical care exchange numerators and denominators were rated as medium level of effort. The commenter expressed that the “number of unique patients with an associated C-CDA document” was rated as high in burden because greater clarification was needed related to what the term “associated” meant.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. In response to public comments, we have revised metrics to reduce burden associated with the measure as further discussed in this section below. We appreciate that aggregating data across clients at the product level requires additional effort even if the incorporation and reconciliation measure is similar to the CMS PI measure, but we maintain that the existence and use of the similar data structures to generate reports for clients creates efficiencies for developers relative to the counterfactual, in which no such data structures currently exist. We believe the measure will provide value commensurate with the burden described by commenters. As noted earlier, commenters representing health care providers expressed value in the proposed incorporation and reconciliation measure. If providers are not engaging in these activities, it would be useful to make that information more widely known to healthcare organizations, payers, and other interested parties involved with patient safety through this measure. Providers may find the measures useful to evaluate their workflows and health IT configuration to optimize functionality that supports incorporation and reconciliation.
                    </P>
                    <P>The version of the metric included in the measure specification is described in more detail below and in the measure specification itself. We have included the following metrics described at 88 FR 23835 in the measure specification: number of encounters during the reporting period, number of unique patients with an encounter during the reporting period, and number of unique patients with an associated C-CDA document during the reporting period. These metrics are included as described at 88 FR 23835, except for a revision to the measure of encounters described further in this preamble.</P>
                    <P>We have revised the metrics, “number of unique C-CDA documents obtained (received or queried) using certified health IT during the reporting period” (88 FR 23835) and “the total number of C-CDA documents of the Continuity of Care Document (CCD), Referral Note, Discharge Summary document types that are obtained and incorporated across all exchange mechanisms through the certified health IT during the reporting period” (88 FR 23836) to better capture how health IT functions and to reduce requirements specific to the Insights Condition. The revisions are further described later in this section.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Numerous commenters requested clarification on whether duplicate documents should be counted and asked how duplicates should be defined. Some commenters recommended that all documents be counted, whether duplicative or not, because all documents must be managed. Furthermore, one commenter recommended that ONC require that all documents are counted, whether considered duplicates or not, because whether documents are duplicates or not, all must be processed, deduplicated, and reconciled. Comments also indicated that deduplication may not be necessary if the intended purpose is to examine trends over time. Commenters noted that there is not necessarily industry consensus on what it means for information to be duplicative. Numerous commenters noted that examining the full content of documents to verify if documents are duplicates may not be feasible. Most commenters indicated that ONC should limit its definition to duplicates based upon document identifiers as that was the most feasible option, though these commenters acknowledged that relying on document identifiers alone to identify them may not fully capture all duplicative documents.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the input from commenters on how the measures should manage duplicate C-CDAs. In response to feedback, the approach to identifying duplicate C-CDAs to support metrics related to unique C-CDA documents, as included in the measure specifications accompanying the HTI-1 Proposed Rule, has been revised. We have removed the requirement for health IT developers to identify C-CDAs that “otherwise contain substantially identical data as identified by developers of certified health IT.”
                        <SU>196</SU>
                        <FTREF/>
                         In the measure specification accompanying this final rule, we have provided a definition for “unique C-CDAs” so that duplicate C-CDAs shall be identified based upon document identifier only, and only one of multiple C-CDAs with the same document identifier will be included in a count of unique C-CDAs. For example, if an HIE receives a C-CDA from a health care provider and regenerates the C-CDA, the content of the document does not change, but the document may have a new document ID. In this instance, we will not require health IT developers to undertake the effort to analyze the content to determine if it is identical to the original C-CDA's content, and we recognize that 
                        <PRTPAGE P="1319"/>
                        C-CDAs containing identical information would not be counted as a duplicate if they have different document IDs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>196</SU>
                             ONC Health IT Certification Program Insights Condition: Consolidated Clinical Document Architecture (C-CDA) Medications, Allergies, and Problems Reconciliation and Incorporation Using Certified Health IT 
                            <E T="03">https://www.healthit.gov/sites/default/files/2023-04/3.Measure_Spec_CCDA_Reconcile_1.3.pdf.</E>
                        </P>
                    </FTNT>
                    <P>We agree with the commenters who highlighted the work necessary to process, deduplicate, and reconcile both non-duplicative and duplicative C-CDAs, and the importance of capturing the totality of all C-CDAs processed. In response to this comment, we have added a metric as the number of total C-CDA documents obtained, inclusive of potential duplicate documents as described in the measure specification. This reflects the totality of documents measured by health IT developers, irrespective of document identifier. This metric relates directly to the proposed metric “number of unique C-CDA documents obtained using certified health IT during the reporting period” (88 FR 23835) and would represent the count of C-CDAs before deduplication processes were applied. Given the substantial comments we received on the deduplication process as described in the measure specification, we believe that this permutation on the underlying metric was both anticipated by and supported by public comment.</P>
                    <P>We have also retained the metric counting the unique number of C-CDAs and have made a revision by modifying the approach to identifying duplicate C-CDAs underlying this metric. The metric, as described in the measure specification accompanying the final rule, is the number of unique C-CDA documents obtained. We clarify that unique C-CDAs are identified by document ID and only one of multiple C-CDAs with the same document identifier counted. This metric relates directly to the proposed metric following revision of the deduplication process. The difference between these two metrics represents the volume of duplicate C-CDAs obtained, determined by document ID. This is critical to track as health care providers have identified the potential negative downstream impacts of duplicate documents exchanged on the complexity of exchange and usability of the data.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Numerous commenters indicated that the proposed metric did not explicitly include important automated aspect of the reconciliation process, which includes deduplication through automated means. Commenters pointed out that reconciliation by human users can be assisted by underlying automation and that there was variation in these practices. For instance, as noted above, commenters expressed concern that there was not industry consensus on how to deduplicate information contained within a C-CDA. The HITAC specifically noted that new tools and automated processes are advancing to reduce the human burden involved in reviewing exchanged information.
                        <SU>197</SU>
                        <FTREF/>
                         Numerous commenters also noted that the measure is specifically based on reconciliation actions occurring at the C-CDA document level, whereas many developers aggregate data across individual documents for consolidated or “bundled” clinical reconciliation for a more user-friendly workflow to deduplicate C-CDAs. Commenters noted the measure should be modified to better account for bundled reconciliation, and that doing so would align this measure further with the CMS PI Program measures. Numerous commenters recommended that ONC include documents reconciled not only by human users, but those documents automatically reconciled via electronic tools that reduce the need for manual review and reconciliation of data. A commenter expressed that the metric was rated as high in burden because auto-reconciliation was not included in the proposed measure.
                    </P>
                    <FTNT>
                        <P>
                            <SU>197</SU>
                             HITAC recommendation: HTI-1-PR-TF-2023_Recommendation 33 in Recommendations on the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI1) Proposed Rule 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2023-06/2023-06-15_HTI-1-PR-TF-2023_Recommendations_Report_Final_508.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate considerations from commenters on the range of evolving practices to automate and support reconciliation and incorporation of C-CDAs, which can reduce burden on end-users. As noted above, given this range of practices, we have specified in the measure specification accompanying this final rule that the identification of unique C-CDAs for the purpose of the Insights Condition depends only on document identifier.
                    </P>
                    <P>
                        In proposing within the measure specification to define duplicates based on the inclusion of substantially identical information as identified by health IT developers, we intended to reflect what we understood to be wide variation in developers' approaches to determining whether information was duplicative.
                        <SU>198</SU>
                        <FTREF/>
                         However, public comments further highlighting variation in approaches to deduplication, particularly automated processes to do so, coupled with comments about similar automated processes that some developers use to reduce burden, indicate that it is essential to measure automated processes to meaningfully capture how information in C-CDAs is used. Without including metrics on these processes, we believe the metrics as proposed may have led to invalid inferences. For instance, the proposed metrics may have inappropriately conflated fully automated processes identifying no new information with processes involving clinician review and resulting in new information incorporated into the Health IT Module. This was confirmed by commenters indicating that it might be infeasible or of little value to implement the proposed metrics in cases where documents were bundled or otherwise pre-processed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>198</SU>
                             ONC Health IT Certification Program Insights Condition: Consolidated Clinical Document Architecture (C-CDA) Medications, Allergies, and Problems Reconciliation and Incorporation Using Certified Health IT 
                            <E T="03">https://www.healthit.gov/sites/default/files/2023-04/3.Measure_Spec_CCDA_Reconcile_1.3.pdf.</E>
                        </P>
                    </FTNT>
                    <P>We further agree with commenters that changes in health IT systems that reduce provider burden are vital. The metrics described in the measure specification accompanying the final rule will facilitate insight into the extent to which health IT systems employ automated processes to streamline reconciliation and incorporation of clinical information and result in greater use of information in C-CDAs and reduced burden. As a result, the measure will properly reflect the success of developers with approaches that create efficiency for the healthcare delivery system.</P>
                    <P>To support the final measure and to capture the range of methods that support the reconciliation and incorporation process, we use several terms in the measure specification sheets accompanying the final rule. For purposes of clarity, we note the terms have the following meanings:</P>
                    <P>• “Pre-Processes for Reconciliation and incorporation” is any automated process that (1) deduplicates C-CDAs, for instance, based on document identifier, the information contained within multiple C-CDAs, or other means; (2) removes information for user review that is identical to information in the Health IT Module; (3) aggregates data across documents for bundled reconciliation; or (4) uses another means to process C-CDAs to facilitate manual (by a clinician or their delegate) or fully automated reconciliation and incorporation of information into the Health IT Module.</P>
                    <P>
                        • “Reconciled and Incorporated via Any Method” is any approach to reconciling and incorporating information in the Health IT Module, including but not limited to manual processes performed by a clinician or their delegate only; a mix of manual and automated processes; or fully automated 
                        <PRTPAGE P="1320"/>
                        processes. This includes an affirmative action to (1) reconcile new information from the C-CDA into the Health IT Module, for instance, by comparison of medication information in the Health IT Module and information in the C-CDA; or (2) indicate that no new information needs to be incorporated into the Health IT Module.
                    </P>
                    <P>• “Fully automated processes for reconciliation and incorporation” is any process by which problems, medications, or allergies and intolerances contained within C-CDAs are automatically reconciled with information within certified health IT and incorporated into health IT without an action by a clinician end-user or their delegate. These processes include (1) reconciling new information from the C-CDA into the Health IT Module, for instance, by comparison of medication information in the Health IT Module and information in the C-CDA; or (2) determining that no new information needs to be incorporated into the Health IT Module.</P>
                    <P>• “Determined to have no new problems, medications, or allergies and intolerances information” is any pre-process or fully automated process that determines that the C-CDA contains no new information.</P>
                    <P>In consideration of public comment received on the proposed measure, we have included more specific metrics in the measure specification accompanying the final rule. Three metrics account for pre-processes and fully automated processes related to reconciling and incorporating C-CDAs and two more clearly framed metrics related to C-CDAs for which automated processes were not applied. We made these adjustments to better reflect developers' existing practices related to deduplication and similar pre-processing, including the bundling of C-CDAs described in public comment on the HTI-1 Proposed Rule and accompanying measurement specification. In contrast to the original measure in the HTI-1 Proposed Rule, we have not finalized a requirement that any complex deduplication be performed specifically for the Insights Condition by those developers who do not currently deduplicate or otherwise automatically process C-CDAs, which will result in reduced burden on developers.</P>
                    <P>In so doing, we believe the updated metrics represent a direct evolution of the focus in the HTI-1 Proposed Rule on deduplication that is responsive to comments and reduces burden on developers. To that end, in the measure specification accompanying this final rule, we sub-divided the proposed metrics to more precisely capture rates of pre-processes and fully automated processes described by commenters.</P>
                    <P>• In addition to the metric, number of unique C-CDA documents obtained, we have also included two metrics to enable the proper and accurate capture of the use of pre-processing that may facilitate efficient and effective review of information contained within C-CDA documents: (1) number of total C-CDA documents obtained that were pre-processed, and (2) number of total C-CDA documents obtained that were not pre-processed. Following the change to what constitutes a duplicate C-CDA previously discussed, the number of unique C-CDAs will reflect elimination of an important subset of duplicate C-CDAs, but will not reflect more complex deduplication processes. The complementary metrics reflect the extent that developers performed pre-processes, inclusive of those deduplication processes, for obtained C-CDAs. This approach eliminates the need to perform specific, complex deduplication processes for the Insights Condition and the final metrics should decrease developer burden compared to what was proposed. We expect that some developers that do not have the capability to pre-process C-CDAs would report a zero for the first metric.</P>
                    <P>• We have divided the proposed metric “number of C-CDA documents of the Continuity of Care Document (CCD), Referral Note, Discharge Summary document types that are obtained and incorporated across all exchange mechanisms supported by certified health IT during the reporting period” into two metrics to more clearly differentiate between reconciliation activities that were and were not supported by pre-processes: (1) number of total C-CDA documents obtained that were pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method; and (2) number of total C-CDA documents obtained that were not pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method. This division was made in response to public comment requesting that we specify how the proposed metrics accounted for pre-processing and requesting that we reduce the complexity of C-CDA processing necessary, specifically for the Insights Condition. We expect that some developers that do not have the capability to pre-process C-CDAs would report a zero for the first measure.</P>
                    <P>Finally, we have included a specific standalone metric to capture fully automated processes that did not result in new information. In the proposed measure specification, we stated, “if no update is necessary, the process of reconciliation may consist of simply verifying that fact or reviewing a record received and determining that such information is merely duplicative of existing information in the patient record.” We believe that this statement was ambiguous about whether automated processes for making this determination would count as reconciliation, and commenters indicated as much by comparison to the CMS PI measure. Given commenters' interest in highlighting various approaches to processing C-CDAs, we have included a metric focused directly on this process as the number of total C-CDA documents obtained that were determined to have no new problems, medications, or allergies and intolerances information by pre-processes or fully automated processes. This metric is intended to disambiguate how to capture pre-processes and fully automated processes for verifying that no new information was available relative to the measure specification accompanying the HTI-1 Proposed Rule.</P>
                    <P>
                        We believe this approach will facilitate measurement of C-CDAs that are bundled together prior to end-user review. For instance, if the bundle is not reviewed by a clinician end user or their delegate and information is not automatically reconciled and incorporated, the metric related to reconciling information that has been pre-processed described above would not include C-CDAs that contained new information presented in a bundle. Prior to manual review, C-CDAs that contributed no new information to the bundle could either be counted as contributing to both the metric related to reconciling information that has been pre-processed and the metric related to determining that the C-CDA contained no new information, or to neither metric depending on the approach that most closely matched the product's logic. Once manual review of a bundled C-CDAs is completed, each C-CDA that comprised the bundled review would increment the metric related to reconciling information that has been pre-processed above, and those that contributed no new information to the bundle would increment the metric related to determining that the C-CDA contained no new information as well. We have adopted this approach to acknowledge the health IT systems that have functionality that streamlines the reconciliation process, with the interest 
                        <PRTPAGE P="1321"/>
                        of understanding how this functionality reduces burden for end users. We recognize that today many developers may apply no pre-processes or fully automated processes to obtained C-CDAs, and these developers would report a zero for these metrics.
                    </P>
                    <P>C-CDA documents obtained via all mechanisms (including from national networks, such as the Carequality framework and CommonWell, Direct Trust, and eHealth Exchange; Health IT Developer networks; EHR to EHR exchange; regional, local, and community HIE; and Direct Secure Messaging) should be counted in the measure. However, we clarify that the measure does not require any stratification by exchange mechanism.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter raised a concern that it would be difficult to deduplicate patients across EHR instances and thus ONC should clarify that deduplication across EHR instances is not expected.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the request for clarification. We recognize that this requirement represents a significant level of burden and do not expect deduplication of patients across EHR instances for this measure.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters recommended to include any valid C-CDA R2.1 IG document-level template for measurement, as opposed to only the CCD, Discharge Summary, and Referral Note templates described in the measure specifications sheets related to this measure. Some commenters also noted that including a broader set of document types would better capture the full scope of C-CDA document exchange that is active in healthcare today and aligns with CMS PI Program. Additionally, one commenter representing health IT developers noted it would be less burdensome to include all documents, rather than only the subset, as they did not have the capability to identify the subset. Relatedly, numerous commenters also suggested that we modify the definition for obtaining C-CDAs. Many commenters indicated that excluding C-CDA without any data would be problematic as that would involve reviewing the content of the C-CDA which would be burdensome. One commenter noted that a C-CDA without any data (such as a patient header) would be rejected and not counted. Some commenters suggested including any document received inbound that is in a valid file format with a header indicating that it is a C-CDA R2.1 document template.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In an effort to align with the “automated measure calculation” (§ 170.315(g)(2)) criterion that health IT developers follow to support reporting the CMS measures, we have revised the measure specification so that the measure includes any valid C-CDA document-level template referred to in the standards adopted for certification to § 170.315(b)(2) for measurement, as opposed to only the CCD, Discharge Summary, and Referral Note templates. This brings the measure into alignment with the CMS PI Program measure (Support Electronic Referral Loops By Receiving and Reconciling Health Information), which states “Starting in 2019, for the Promoting Interoperability measure an EP may use any document template within the C-CDA standard for the purposes of the measure.” We note that this scope is substantially broader than the “clinical information and reconciliation and incorporation” (§ 170.315(b)(2)) criterion, which only requires that certified Health IT Modules be able to reconcile and incorporate Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary. We will not require developers to exclude documents without data, acknowledging that some developers do not parse or otherwise pre-process C-CDAs and, therefore, cannot readily evaluate whether the C-CDA contains data. We plan to collaborate with the community to determine if more nuanced levels of analysis are warranted for future measure updates to refine the measure.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters asked ONC for clarification on the proposed denominator, “number of unique patients with an associated C-CDA document during the reporting period.” One commenter indicated they were not sure how it differed from “documents obtained” in one of the other denominators and whether it was intended to only capture new associations that occurred during a reporting period or a snapshot of all patients at the end of the reporting period. One commenter also inquired about how to count a document received during one reporting period but matched in another reporting period.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We clarify that the metric, number of unique patients with an associated C-CDA document during the reporting period, refers to the number of unique patients that have been matched to at least one C-CDA within the certified Health IT Module by automated or manual means in the reporting period and, therefore, have at least one associated C-CDA. The metric, number of total C-CDA documents obtained through certified health IT during the reporting period, refers to the total number of C-CDA documents obtained across all patients for the reporting period. For example, if two C-CDAs were received for a single patient during the reporting period, the first metric would count this as a single unique patient, while the second metric would count this as two C-CDAs. These counts would not depend on whether information had previously been received for a patient prior to the reporting period. As noted in the HTI-1 Proposed Rule, we believe these denominators support an understanding of the volume of C-CDA documents exchanged relative to the number of instances when external information could inform health care providers.
                    </P>
                    <P>With regard to documents that may be obtained in one reporting period and reconciled in another reporting period, the measure's metrics call for counting C-CDAs obtained, reconciled, and incorporated in the same reporting period. We recognize that some C-CDAs obtained prior to the reporting period, but reconciled and incorporated during the reporting period, are not counted in the metrics. However, we expect these instances will not substantially impact the interpretation of the metrics' results. We also recognize that some C-CDAs obtained during the reporting period may be reconciled and incorporated following the reporting period, but similarly believe these instances will be uncommon. We expect that the shift to calendar year reporting will further minimize the exclusion of documents that are received before the start of a reporting period and reconciled during the start of the reporting period.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested the encounter-based metrics may not adequately measure one of the key areas of interest, which is to assess the extent to which exchange of outside information can potentially inform care. This commenter suggested that to identify the extent to which encounters benefited from information exchange would require a denominator of total number of encounters during the reporting period, and a numerator of encounters in which information from a C-CDA document was incorporated. Such a measure would provide the percentage of encounters in which outside information was potentially beneficial to the encounter was incorporated from received documents.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree with the commenter that many variations on the required metrics could provide additional insight into how exchanged information is used and that measures related to the proportion of encounters in which obtained information was incorporated could be particularly insightful. However, we have sought to 
                        <PRTPAGE P="1322"/>
                        balance that consideration against the potential for additional burden associated with the measure. To that end, we decline to revise or extend measures to capture the proportion of encounters in which information was incorporated. We plan to continue to collaborate with the community to investigate the degree of development necessary to link C-CDAs incorporated to their use to inform care during an encounter.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters raised questions regarding what actions count as reconciliation. One commenter requested clarification on whether a document would be considered incorporated if any amount of data was incorporated or by specific data element. A couple of commenters requested ONC be more explicit about what types of data are included for reconciliation, asking whether a document should be included only if it had problems, allergies, or medications (PAM) for reconciliation, or if reconcilable laboratory results (
                        <E T="03">e.g.,</E>
                         blood tests) or immunizations should also be included. A commenter requested that ONC limited it to reconciliation of PAM, given that it is a certification requirement, and that the numerator be explicitly defined in that manner. Relatedly, a couple of commenters recommended that if a document did not contain any new information to be reconciled that it should still increment the numerator to match the existing CMS PI measure. Another commenter requested that ONC clarify that viewing documents is not equivalent to reconciling documents.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Our intent is to align the measure requirements with the “clinical information reconciliation and incorporation” (§ 170.315(b)(2)) certification criterion. As such, we describe in the measure specification accompanying the final rule that metrics related to reconciliation of C-CDAs would increment upon reconciliation of medications, allergies and intolerances, or problems. The two metrics are: (1) number of total C-CDA documents obtained that were pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method; and (2) number of total C-CDA documents obtained that were not pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method. We clarify that the increment occurs when reconciliation is completed for any one of the three types of data, that is, when at least one medication, allergy and intolerance, or problem is reconciled and incorporated or when it is determined that no new information should be incorporated. We agree with the recommendation from commenters that documents that do not contain any new information for reconciliation should still increment the metrics when an end-user or automated process verifies the fact that information in the C-CDA is duplicative of existing information in the patient record to match the existing CMS PI measure. The third metric, number of total C-CDA documents obtained that were determined to have no new problems, medications, or allergies and intolerances information by pre-processes or fully automated processes, would also increment when automated processes were used to make this determination. We believe that distinguishing between automated processes that identify no new information and other reconciliation is important for a valid understanding of the use of information and burden on end-users. We clarify that the act of simply viewing a C-CDA, without an affirmative action verifying that information is either absent or duplicative, would not increment these metrics.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested focusing measurement on transitions between outside organizations/systems, as patients within health systems are often referred, admitted, and discharged to providers within the same system which might make it difficult to interpret the results.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The measure is intended to count C-CDAs that must be exchanged outside of a “one patient one chart” system, where multiple specialists within a system can access a single patient record and manage a single list for problems, medications, and medication allergies. We note that this measure applies to intra-system exchange, where specialists within the same provider organization do not have access to a “one patient one chart” health IT system, and inter-system exchange, where specialists across different provider organizations also do not have access to a “one patient one chart” health IT system. We also note that this measure is not limited to transitions of care. We may consider if the measure should be reported by transitions of care in future rulemaking.
                    </P>
                    <HD SOURCE="HD3">Finalization of Measure</HD>
                    <P>We have finalized the measure as “consolidated clinical document architecture (C-CDA) problems, medications, and allergies reconciliation and incorporation through certified health IT” in § 170.407(a)(3)(ii). We have revised the proposed measure based on public comments received related to variation in industry practices, including approaches to deduplication and automation. Specific metrics to support this finalized measure are described in the related measure specification located on ONC's website and in the section above. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion:</P>
                    <P>1. Number of encounters</P>
                    <P>2. Number of unique patients with an encounter</P>
                    <P>3. Number of unique patients with an associated C-CDA document</P>
                    <P>4. Number of total C-CDA documents obtained</P>
                    <P>5. Number of unique C-CDA documents obtained</P>
                    <P>6. Number of total C-CDA documents obtained that were pre-processed</P>
                    <P>7. Number of total C-CDA documents obtained that were not pre-processed</P>
                    <P>8. Number of total C-CDA documents obtained that were pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method</P>
                    <P>9. Number of total C-CDA documents obtained that were not pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method</P>
                    <P>10. Number of total C-CDA documents obtained that were determined to have no new problems, medications, or allergies and intolerances information by pre-processes or fully automated processes</P>
                    <P>The reporting period for the measure and related metrics consists of one calendar year. Data collection for the measures and associated metrics will begin during the second and third phases of reporting (which is described later in the preamble).</P>
                    <HD SOURCE="HD3">Measurement Area: Standards Adoption and Conformance</HD>
                    <P>
                        We proposed (88 FR 23837) to adopt four measures in the “standards adoption and conformance” area in § 170.407(a)(4) through (7) to provide insight into the role that standards play in enabling the access, exchange, and use of EHI. We proposed to measure the following aspects within this area: (1) availability of apps to support access to EHI for a variety of purposes; (2) the usage of FHIR-based APIs to support apps; (3) the use of bulk FHIR to support the access to EHI for groups of individuals; and (4) the use of EHI 
                        <PRTPAGE P="1323"/>
                        export functionality (88 FR 23837). We stated that together, these measures will provide a foundation for understanding whether and to what extent ONC's policies to promote standards are supporting users of health IT, including patients, clinicians, researchers, and others to access, exchange, and use EHI via certified health IT for a variety of purposes. These measures would also provide visibility into industry adoption of standards required by the Program and provide data to inform future standards development work.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters supported the “standards adoption and conformance” measurement area. One commenter expressed support for interoperability measurement as a national priority. One commenter disagreed with ONC's statement that data on the volume of information exchanged would provide the means to assess the extent that patient information is moving between providers to facilitate high value care, stating that pure volume does not accurately reflect quality.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support expressed by many commenters and agree that only collecting data on the volume of information exchanged will not strictly reflect the quality of care provided. However, we plan to use this data in conjunction with other collected data from the “Insights Condition and Maintenance of Certification” to create metrics that will assess the extent that patient information is exchanged between providers to facilitate high value care.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received numerous comments with suggestions for new or revised measures in the “standards adoption and conformance” area. Throughout this measurement area we use the abbreviation “app” for the term application. Apps that may connect to ONC-certified health IT via the capabilities enabled by 170.315(g)(10), refer to third-party software or IT system not offered by the certified health IT developer including but not limited to: mobile apps, web portals, locally hosted software, enterprise software solutions, and custom software.
                    </P>
                    <P>
                        For the “applications supported through certified health IT” measure, the majority of comments received suggested metrics focused on the availability (
                        <E T="03">e.g.,</E>
                         number of distinct apps) and accessibility (
                        <E T="03">e.g.,</E>
                         number of accesses) of patient-facing and non-patient-facing apps. Two commenters suggested metrics focused on requesting additional qualitative context/information about the purpose for which apps were developed or use cases, especially for specialty care apps, and clinical decision support. One commenter requested for app developers to report the turnaround time for app developer authentication and authorization to production environments. One commenter requested for app attestation to be included in the Insights Condition requirements.
                    </P>
                    <P>For the “use of FHIR in apps supported by certified API technology” measure, a majority of the comments suggested metrics focused on IG development, adoption, and conformance beyond the US Core IG. One commenter requested a metric that counts the number of queries made by either a patient or a clinician. One commenter suggested counting the total number of FHIR resources by individual resource.</P>
                    <P>
                        For the “use of FHIR bulk data access through certified health IT” measure, most of the commenters suggested metrics focused on obtaining information related to the FHIR Bulk Data request metadata (
                        <E T="03">i.e.,</E>
                         user-type of the FHIR Bulk Data requester, export time per resource (average), and group size for successful exports (average)). One commenter suggested a metric that counts the number of FHIR Bulk Data export requests. Another commenter suggested a metric that focuses on real-world performance of FHIR Bulk Data implementations.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank all commenters for their thoughtful input. We appreciate the interest expressed in requiring additional reporting metrics for the “standards adoption and conformance” measurement area, and may explore the feasibility of these suggested reporting metrics in the future.
                    </P>
                    <HD SOURCE="HD3">Applications Supported Through Certified Health IT Measure</HD>
                    <P>In the HTI-1 Proposed Rule (88 FR 23837), we proposed to adopt the “applications supported through certified health IT” measure in § 170.407(a)(4), which would provide information on how certified health IT supports the health app ecosystem by asking certain health IT developers under the Program to report app names and app developer names, intended app purposes, intended app users, and whether a registered app is in “active” use across a developer's client base (as further detailed below). We stated in the HTI-1 Proposed Rule that this measure would result in a listing of apps that could be used to generate a variety of metrics. Only developers of certified health IT with Health IT Modules certified to the “standardized API for patient and population services” (§ 170.315(g)(10)) criterion would be required to report data for this measure.</P>
                    <P>In the HTI-1 Proposed Rule (88 FR 23837 through 23840), we proposed that developers of certified health IT with Health IT Modules certified to § 170.315(g)(10) provide certain information about the apps that are connected to their certified technology. We proposed that the app name and the developer (company/organization or individual) responsible for the app would be reported for each app registered to a developer of certified health IT whose Health IT Module is certified to the § 170.315(g)(10) criterion. We noted that the app registration process required under § 170.315(g)(10)(iii) may provide an opportunity for developers of certified health IT to gather standard information for apps connecting to their certified API technology as part of existing workflows. There may be other mechanisms besides the app registration process by which developers of certified health IT wish to obtain this information.</P>
                    <P>We proposed that developers of certified health IT with Health IT Modules certified to § 170.315(g)(10) obtain and report the intended purpose(s) for each app connected to their certified API technology using the following categories:</P>
                    <P>
                        • Administrative Tasks (
                        <E T="03">e.g.,</E>
                         scheduling &amp; check-in, billing &amp; payment)
                    </P>
                    <P>
                        • Clinical Tools (
                        <E T="03">e.g.,</E>
                         clinical decision support, risk calculators, remote patient monitoring)
                    </P>
                    <P>
                        • Individuals' Access to their EHI (
                        <E T="03">e.g.,</E>
                         enables patients to access their health information, medications, test results, vaccine records)
                    </P>
                    <P>
                        • Research (
                        <E T="03">e.g.,</E>
                         used to perform clinical research)
                    </P>
                    <P>
                        • Population Data (
                        <E T="03">e.g.,</E>
                         bulk transfer of data, population analytics &amp; reporting)
                    </P>
                    <P>
                        • Public Health (
                        <E T="03">e.g.,</E>
                         electronic case reporting)
                    </P>
                    <P>
                        • Patient-Provider Communication (
                        <E T="03">e.g.,</E>
                         secure messaging, telehealth)
                    </P>
                    <P>
                        • Educational Resources (
                        <E T="03">e.g.,</E>
                         patient and provider educational resources)
                    </P>
                    <P>• Other Intended Purpose</P>
                    <P>
                        • Unknown (
                        <E T="03">e.g.,</E>
                         missing)
                    </P>
                    <P>
                        As stated in the HTI-1 Proposed Rule (88 FR 23838), developers of certified health IT to whom the measure applies would report the intended purpose(s) of the app for each app registered to their Health IT Module(s) certified to the § 170.315(g)(10) criterion. The categories we proposed under this measure were informed by app category taxonomies in published literature from Barker &amp; 
                        <PRTPAGE P="1324"/>
                        Johnson (2021),
                        <SU>199</SU>
                        <FTREF/>
                         Ritchie and Welch (2020),
                        <SU>200</SU>
                        <FTREF/>
                         and Gordon and Rudin (2022).
                        <SU>201</SU>
                        <FTREF/>
                         While we recognized this taxonomy may need to evolve over time, we conveyed in the HTI-1 Proposed Rule our belief that the proposed categories represented a large majority of the current market, and that the types of information, if reported on a complete set of apps, would provide insightful information to guide ONC's future efforts to support individuals' access to their EHI via apps, along with other priority uses, such as research and clinical care.
                    </P>
                    <FTNT>
                        <P>
                            <SU>199</SU>
                             The ecosystem of apps and software integrated with certified health information technology: 
                            <E T="03">https://academic.oup.com/jamia/article/28/11/2379/6364773?login=false.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>200</SU>
                             Categorization of Third-Party Apps in Electronic Health Record App Marketplaces: Systematic Search and Analysis: 
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7293052/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>201</SU>
                             Gordon WJ, Rudin RS. Why APIs? Anticipated value, barriers, and opportunities for standards-based application programming interfaces in healthcare: perspectives of US thought leaders. JAMIA Open. 2022 Apr 6;5(2):ooac023. doi: 10.1093/jamiaopen/ooac023. PMID: 35474716; PMCID: PMC9030107.
                        </P>
                    </FTNT>
                    <P>Additionally, we proposed (88 FR 23838) that developers of certified health IT with Health IT Modules certified to § 170.315(g)(10) obtain the following intended user(s) categories for each app connected to their certified API technology:</P>
                    <P>• Individual/Caregiver</P>
                    <P>• Clinician</P>
                    <P>• Healthcare Organization</P>
                    <P>• Payer</P>
                    <P>• Researcher</P>
                    <P>• Other Intended User</P>
                    <P>
                        • Unknown (
                        <E T="03">e.g.,</E>
                         missing)
                    </P>
                    <P>We also proposed (88 FR 23838) that developers of certified health IT with Health IT Modules certified to § 170.315(g)(10) obtain the status for each app connected to their certified API technology using the following categories:</P>
                    <P>• Actively Used—An app is defined as “Actively Used” if EHI has been transferred to the app using certified API technology for 10 or more unique patients during the reporting period</P>
                    <P>• Not Actively Used—An app is defined as “Not Actively Used” if EHI has been transferred to the app using certified API technology for fewer than 10 unique patients during the reporting period</P>
                    <P>
                        <E T="03">Comments.</E>
                         Most commenters, including EHR and app developers, as well as commenters representing health care providers, were generally supportive of this measure and provided specific requests for clarification and recommendations to constrain the measure. Several commenters indicated that the data collection burden is high for this measure. One commenter expressed concerns that the reporting of these data could lead the public to believe that health IT developers had a role in recruiting application developers to connect to § 170.315(g)(10). Another commenter recommended that this information be collected directly from application vendors to reduce burden on health IT developers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their general support. We believe this measure provides greater transparency regarding apps that are connected to certified health IT. Specifically, this measure would enable ONC and the public to understand to what degree apps are connecting across different certified health IT products, which is important for enabling individuals' access to their EHI. The ONC Cures Act Final Rule (85 FR 25750) emphasized the importance of standardization, transparency, and pro-competitive business practices through the API Condition and Maintenance of Certification requirements that would make it easier for third-party apps to connect to certified health IT, and subsequently facilitate individuals' access to their EHI. This measure also provides insights into the types of apps that integrate with certified health IT. Collecting this information will be beneficial to developers as well, for it will provide them with insights about available technologies and uses for data that are in demand in the marketplace.
                    </P>
                    <P>We acknowledge that collecting this information may require new or updates to existing data collection as part of the app developer registration processes. Although developers expressed concerns related to the burden associated with collecting this information, most commenters indicated that they have an existing app registration process, and thus we believe that developers of certified health IT are best positioned to collect and report this measure. The app registration process would provide an opportunity to gather standard information for apps connecting to their certified health IT as part of existing workflows. We currently do not have data regarding which apps are connected to their developers' health IT and thus cannot directly collect this information. We also recognize that health IT developers do not recruit application developers to connect to certified health IT, but rather are collecting this information among those application vendors that are connected to their systems and through the app registration processes.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Numerous commenters recommended that ONC directly acknowledge that mandatory collection of intended purposes and intended users via the health IT developer registration process would not violate the API Condition of Certification. One health IT developer expressed concern that some of the measures will require collection of new types of data, specifically app categories and audiences. Commenters representing app developers indicated they supported this measure and furthermore had suggestions for additional measures to include.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments, and note that the collection of app information required for this Insights Condition measure will not violate the API Condition and Maintenance of Certification (§ 170.404(b)). Specifically, the requirements in § 170.404(b) enable a Certified API Developer to institute its own process to register applications for production use, so long as it occurs within five days of completing its verification of an API User's authenticity. We do not believe requiring app developers to provide basic information such as the characteristics of their application, including intended users and purpose, to be creating undue burden on app developers. Given the support we received for this measure, including from app developers, we do not believe this will be a widespread concern or issue. However, we remind Certified API Developers that the registration process must still occur in the allotted five business days of completing its verification of an API User's authenticity, pursuant to paragraph § 170.404(b)(1)(i) and consistent with § 170.404(b)(1)(ii).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters had questions related to which apps would be subject for inclusion in this measure. Commenters representing EHR developers inquired whether applications relevant for this measure would be exclusively those registered for and using the scope of FHIR resources required under the scope of the relevant program criterion at § 170.315(g)(10). Another commenter indicated that some § 170.315(g)(10) certified health IT does not transfer patient EHI and requested clarification on whether this technology would be subject to reporting for this measure.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback and offer the following clarifications. Any app that is registered via the app registration process for the § 170.315(g)(10) criterion is subject for inclusion in this measure.
                        <E T="03"/>
                         We note that the apps that are used by a variety of interested parties to interact with health 
                        <PRTPAGE P="1325"/>
                        IT certified to § 170.315(g)(10) are in scope and could include, but are not limited to, provider-, patient-, and payer-oriented apps. This variety is also reflected in the category of intended user types we plan to collect. We did not fully understand the comment regarding a § 170.315(g)(10) certified health IT that does not transfer patient EHI because that is the primary point of such technology. As a result, we are unable to provide further clarity in response to the comment aside to reiterate that all apps registered through the § 170.315(g)(10) app registration process is in scope for this measure.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters indicated that it would be difficult to collect additional information from app developers that are already registered with their certified health IT and that new information will not be collected until app developers need to re-register their app. Thus, ONC should expect a disproportionate number of “unknown” entries related to intended purpose of app and users during early years of reporting. Another commenter indicated that it would be unable to capture this information for applications that do not register with the developer of certified health IT. One commenter noted that with a dynamic client registration process, where the registration of applications with an authorization server would be done dynamically using a trust framework, might lead to attributes needing to be collected as part of the registration assertion process. They recommended that this may need to be reviewed, perhaps by a FHIR at Scale Taskforce (FAST) workgroup.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments, and recognize that the measure data may not be as comprehensive initially as it will be in future years since the year 2026 will be the first measure collection phase and some health care providers will still be implementing § 170.315(g)(10) upgrades. Thus, there may be many “unknown” entries in early years of reporting, and as apps re-register, this information would be provided. Many developers certified to § 170.315(g)(10) may require app developers to register via a process that allows for the collection of the data required for this measure. To the commenter who indicated app information may be missing for those apps that do not register, we recognize that apps not connected to the certified (§ 170.315(g)(10) API (and therefore not required to register) would not be included. We also note that while the app registration process required under § 170.315(g)(10)(iii) may provide an opportunity to collect this information, developers of certified health IT may wish to use other mechanisms such as surveys, forms, or health IT system-based methods to obtain this information. We are not limiting or specifying the methods by which developers of certified health IT collect this information. Developers should describe the method(s) they used to collect the data in the required documentation they submit to ONC. Further, we believe it will be possible to collect these data through the dynamic client registration process; however, we note that existing dynamic registration implementation guides may need additional specification. We appreciate the recommendation to consult with a FAST workgroup or other groups working on dynamic client registration to ensure that this step is included as part of that process.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter supported the proposed collection of user type (intended user of app) for apps and encouraged collection of information that would identify the types of users that are the focus of the app (
                        <E T="03">e.g.,</E>
                         patient, provider, system) to the dataset of information collected about apps. Another commenter requested clarification between “clinician” and “healthcare organization.” One commenter suggested that the value sets for metrics, intended purpose of app and intended user of app, be based upon a standardized value set referenced in other interoperability initiatives such as TEFCA and HL7 Role Class, respectively. One commenter also noted that some apps may have multiple intended purposes and intended users and wanted to confirm that reporting of multiples where relevant was acceptable.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the input provided by commenters on establishing or selecting an available value set for intended purpose and intended user. We agree that “clinician” and “healthcare organization” may seem duplicative and to avoid confusion we have revised the value set by removing both of these options and replacing “clinician” with “clinical team” and “healthcare organization” with “healthcare administrator/executive.” We appreciate the recommendation to consider standardized value sets and may consider identifying relevant value sets in future rulemaking. With regards to selection of metrics, intended purpose, and intended user, we understand that there may be multiple purposes and users so apps should select all that apply and not be limited to one response. Therefore, these are the following intended user(s) categories for each app connected to their certified health IT:
                    </P>
                    <FP SOURCE="FP-1">• Individual/Caregiver</FP>
                    <FP SOURCE="FP-1">• Clinical Team</FP>
                    <FP SOURCE="FP-1">• Healthcare Administrator/Executive</FP>
                    <FP SOURCE="FP-1">• Payer</FP>
                    <FP SOURCE="FP-1">• Researcher</FP>
                    <FP SOURCE="FP-1">• Other Intended User</FP>
                    <FP SOURCE="FP-1">
                        • Unknown (
                        <E T="03">e.g.,</E>
                         missing)
                    </FP>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested clarification on whether an application is “actively used” or “not actively used,” noting applications that are “not actively used” are not a reflection of the certified health IT. One commenter recommended that an application should be designated as actively used based upon either a particular threshold of total API call volume, or total authorization events constituting a unique user session for the app. The commenter indicated that this approach would help ensure that apps used in high frequency for retrieving health information on a small number of patients are not erroneously classified as “not actively used.” The same commenter expressed concern about a threshold of 10 or more unique patients, indicating that an app that is used daily by fewer patients should still be considered “actively used,” especially for developers that may only serve a smaller scope of providers. Another commenter suggested an additional category of “evaluating” that represents an app is connected but used by fewer individuals (such as 3 or 5), along with a “superactive” designation for larger numbers of individuals, therefore creating four categories, rather than two.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. We realize that usage of apps is not necessarily a reflection on health IT developers. However, this information is critical to collect in order to distinguish between production apps that are registered and are in use (
                        <E T="03">e.g.,</E>
                         10 or more unique patients), production apps that are registered and are not in use (
                        <E T="03">e.g.,</E>
                         less than 10 unique patients), and production apps that are registered but not enabled by the health IT developer. Without this information, the value of the overall data would be limited.
                    </P>
                    <P>
                        The definition of active use is described in our measure specification. The definition is based on whether EHI has been transferred to the app using certified health IT for ten (10) or more unique patients during the reporting period. By setting the threshold at ten or more unique patients, we expect that this threshold will represent active use. While mobile patient portal apps and well-known healthcare apps (
                        <E T="03">e.g.,</E>
                         Apple 
                        <PRTPAGE P="1326"/>
                        Health) have large user bases, for lesser-known healthcare apps that filled specific healthcare segments (
                        <E T="03">e.g.,</E>
                         rare or terminal diseases, chronic or hereditary diseases, age-related conditions, pediatrics, behavioral and mental health), ONC expects smaller user bases.
                        <SU>202</SU>
                        <FTREF/>
                         An ONC internal analysis of the Google Play
                        <E T="51">TM</E>
                         store data found that the number of Android installs for apps that enable patients to access their data, ranged from 4 to over 400,000. There is little public data on number of users specifically, and thus, in setting the criteria of active use, we are relying upon the number of installs for these types of apps, even though it is not equivalent to the number of users. A mix of self-reported data show approximately 3.87 million people use health and fitness apps, and data from app stores list approximately 350,000 mobile health apps (many of which include apps that do not integrate with EHRs and are not applicable to this metric); on average, health apps have approximately 11 users each.
                        <SU>203</SU>
                        <FTREF/>
                         However, none of these data sources provide data on actual use for the apps that connect with EHRs. We aim to be broad in determining active use and balance the need to define app use to include apps that have a smaller target audience. Thus, we have set a relatively low threshold of ten or more unique patients for defining active use. We appreciate the alternative suggestions for measuring whether an app is actively used. However, using total API call volume to measure usage would skew results and make it difficult to determine appropriate level of API calls to qualify for “active use,” as certain apps may make API calls multiple times per day. A lower threshold of less than ten users that would also take into account the use of apps on a daily or weekly basis may be more complex to implement, as this also involves measuring the frequency of use (as opposed to simply the number of users). Also, the call or requested data (which would be used to assess frequency of use) may be difficult to interpret as apps using APIs regularly request data from providers as part of their process to update the data within the app, and it may not reflect user driven behavior. The other suggested alternative, using authorization events, could be difficult to implement because it would be difficult to determine the number of authorization events that would define whether an app is actively used given the number of authorization events could vary by individual and app. However, we plan to continue collaborating with the community to assess level of usage using authorization events for future iterations of this measure.
                    </P>
                    <FTNT>
                        <P>
                            <SU>202</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2020-11/Accelerating_APIs_Consumer_Perspective.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>203</SU>
                             
                            <E T="03">https://www.mobius.md/2021/10/25/11-mobile-health-statistics/.</E>
                        </P>
                    </FTNT>
                    <P>With regards to expanding usage from two to four categories, we may consider expanding categories in the future.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A couple of commenters also had questions about the inclusion of apps as of the last day of the reporting period (
                        <E T="03">i.e.,</E>
                         report only existing apps as of the last day of the reporting period) or whether apps should be included based upon whether they had registered at any point during the reporting period (
                        <E T="03">i.e.,</E>
                         report all apps that had been registered during the reporting period, even if they are not registered on the last day of the reporting period). A commenter suggested counting the total number of apps active at any point in the reporting period to appropriately account for onboarding and offboarding activity, whereas a couple of commenters noted that reporting of the app status is not a metric that is measured over a reporting period and would be an indication at a point in time at the end of the reporting period.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We clarify that the app status (
                        <E T="03">e.g.,</E>
                         usage) should include apps based upon whether they had registered at any point in time during the reporting period. We seek to measure the unique number of individuals who used the app during the reporting period (a calendar year) and do not want to limit the inclusion to apps that are registered as of the last day of the reporting period. For apps that were registered during the reporting period and are not registered at the end of the reporting period, we would want their status to be calculated and included. 
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter representing medical professionals recommended that as part of this measure, ONC include a metric requiring health app developers to attest to whether they adhere to (yes/no) any of the following: (1) Industry-recognized development guidance (
                        <E T="03">e.g.,</E>
                         Xcertia's Privacy Guidelines/Privacy Is Good Business: a case for privacy by design in app development); (2) Transparency statements and best practices (
                        <E T="03">e.g.,</E>
                         Mobile Health App Developers: FTC Best Practices/CARIN Alliance Code of Conduct/AMA Privacy Principles); and/or (3) A model notice to patients (
                        <E T="03">e.g.,</E>
                         ONC's Model Privacy Notice). The commenter noted that almost all patients want transparency on how apps access, exchange, or use their medical information, and this would address that need.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for their recommendations to include a metric on an app developer's adherence to various privacy and security practices and frameworks. We may consider these recommendations in future rulemaking. We also refer readers to other federal regulations such as Section 5 of the FTC Act,
                        <SU>204</SU>
                        <FTREF/>
                         Children's Online Privacy Protection Act (COPPA) 
                        <SU>205</SU>
                        <FTREF/>
                         and the COPPA Rule,
                        <SU>206</SU>
                        <FTREF/>
                         and other industry initiatives 
                        <SU>207</SU>
                        <FTREF/>
                         supporting consumers in app privacy, security, and transparency.
                    </P>
                    <FTNT>
                        <P>
                            <SU>204</SU>
                             
                            <E T="03">https://www.federalreserve.gov/boarddocs/supmanual/cch/200806/ftca.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>205</SU>
                             
                            <E T="03">https://www.govinfo.gov/content/pkg/PLAW-105publ277/pdf/PLAW-105publ277.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>206</SU>
                             
                            <E T="03">https://www.ftc.gov/legal-library/browse/rules/childrens-online-privacy-protection-rule-coppa.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>207</SU>
                             
                            <E T="03">https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Finalization of Measure</HD>
                    <P>We have finalized the “applications supported through certified health IT” measure in § 170.407(a)(3)(iii). We have revised the proposed measure based on public comments received. Specific metrics to support this finalized measure are listed below and described further in the accompanying measure specification located on ONC's website. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion.</P>
                    <FP SOURCE="FP-1">1. Application Name(s);</FP>
                    <FP SOURCE="FP-1">2. Application Developer Name(s);</FP>
                    <FP SOURCE="FP-1">3. Intended Purpose(s) of Application;</FP>
                    <FP SOURCE="FP-1">4. Intended Application User(s); and</FP>
                    <FP SOURCE="FP-1">5. Application Status.</FP>
                    <P>The reporting period for the measure and related metrics above consists of one calendar year. Data collection for the measures and associated metrics will begin during the first phase of reporting (which is described later in the preamble).</P>
                    <HD SOURCE="HD3">Use of FHIR in Apps Through Certified Health IT Measure</HD>
                    <P>
                        In the HTI-1 Proposed Rule (88 FR 23839), we proposed the adoption of the “use of FHIR in apps supported by certified API technology” measure in § 170.407(a)(5), which would capture the volume of FHIR resources transferred in response to API calls from apps connected to certified API technology by FHIR resource type. We also proposed (88 FR 23839) that the FHIR resources transferred be reported by FHIR version used and by US Core Implementation Guide version 
                        <PRTPAGE P="1327"/>
                        deployed. This measure also proposed requiring developers to report FHIR resources transferred in response to calls from two different endpoint types: patient-facing and non-patient-facing, the latter of which would include endpoints that do not facilitate individuals' access (
                        <E T="03">e.g.,</E>
                         clinician, payer, or public health endpoints). We explained that this measure proposed to require developers of certified health IT with Health IT Modules certified to the “standardized API for patient and population services” (§ 170.315(g)(10)) certification criterion to report on the number of deployments they support across their customer base, and that together, these data points would provide insights into the usage of certified APIs by collecting data on the volume of FHIR resources transferred to apps in response to API calls by FHIR resource type, type of endpoint, and US Core Implementation Guide used.
                    </P>
                    <P>
                        We proposed (88 FR 23839) the first numerator to be the number of FHIR resources returned/transferred in response to a call to a certified API technology by resource type. We proposed the second numerator to be the number of distinct certified API technology deployments (across clients) associated with at least one FHIR resource returned/transferred in response to a call. We noted that each of the numerators would be stratified (
                        <E T="03">e.g.,</E>
                         divide into subsets) by type of endpoint (patient-facing vs. non-patient-facing), by FHIR version, and by US Core Implementation Guide.
                    </P>
                    <P>We proposed (88 FR 23839) the denominator to be the total number of distinct certified API technology deployments (across clients). In addition, we proposed this denominator to be stratified by type of endpoint (patient-facing vs. non-patient facing), FHIR version, and US Core Implementation Guide. We noted that non-FHIR APIs, such as those represented with proprietary standards, are excluded from this measure, including numerators and denominators. We refer readers to the HTI-1 Proposed Rule for a complete listing of the metrics this measure would enable us to calculate (88 FR 23839). As stated in the HTI-1 Proposed Rule, this measure would require that developers report the volume of FHIR resources transferred in response to calls by FHIR version and by US Core Implementation Guide. While Health IT Modules certified to § 170.315(g)(10) are required to respond to requests according to FHIR version Release 4, we are aware that there will be newer versions of FHIR supported by newer versions of the US Core Implementation Guide. Gaining insights into the frequency in use of US Core Implementation Guides will inform ONC of the variability in the implementation of FHIR across developers.</P>
                    <P>We requested feedback on whether information on both aspects of the measure, FHIR version and US Core Implementation Guide, are necessary as each provides unique insights, or whether focusing on one of these (either FHIR version or US Core Implementation Guide) would be sufficient to understand where the industry is in the implementation of FHIR. We also requested comment on the feasibility of reporting the use of different HL7 FHIR implementation guides and FHIR versions, versus being stratified by type of endpoint, type of FHIR resources, and by the number of certified API technology deployments (88 FR 23840).</P>
                    <P>We also proposed (88 FR 23840) to require developers of certified health IT to whom the measure would be applicable to report the number of certified API technology deployments (as a proxy for organizations that have installed certified API technology) where FHIR resources were transferred in response to a call (relative to the total number of certified API technology deployments). We stated that this information can shed light on whether usage is concentrated versus dispersed, indicating the breadth of usage across end users and organizations. However, given that API deployments may vary across developers, we sought feedback on whether this measure would be a good proxy for understanding usage across their client bases.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters expressed support for the proposed measure. Two commenters, one of which represents ONC's Health IT Advisory Committee, indicated the support for metrics that would help inform the future development of interoperability standards, including versions and variations. Commenters indicated these data would provide use of standards in the field that can shed light on industry-wide readiness for the adoption of standards, such as those adopted through Standards Version Advancement Process (SVAP). One commenter suggested to delay or eliminate the measure. Commenters representing community healthcare associations expressed support for this measure, stating that this measure benefits community health centers by measuring the interoperability and seamless data exchange between healthcare applications and exchange partners, which leads to better care coordination and improved population health outcomes.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support and believe that these measures provide real-world usage data to help guide and inform the future development of interoperability standards, and therefore we do not plan to eliminate this measure as suggested by one commenter. While the data for this measure will be collected in the first year of the Insights Condition (CY 2026), the first response submission period has been delayed to July, 2027 to provide more time to implement the measure and reduce burden. More details on the compliance dates associated with all the measures can be found in section III.F.3.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A couple of commenters provided qualitative ratings of burden associated with the metrics. One commenter indicated that the first metric (number of FHIR resources returned/transferred in response to a call to a certified health IT by resource type) would be medium level of effort; whereas the other commenter indicated that first metric would be high level of effort. Both commenters indicated that the second metric (number of distinct certified health IT deployments (across clients) associated with at least one FHIR resource returned/transferred in response to a call) would be low level of effort. A couple of other commenters requested additional clarity on whether the first metric intends for developers to report the number of total resources returned for each resource, or the number of requests that returned at least one (1) resource for each resource. For example, if a request returns 100 different Observations, would that be considered a count of 1 or 100 total resources. Two commenters recommended defining the first metric to be the total number of resources returned. Another commenter recommended simplifying the metric by measuring only the number of queries or requests made by patients and by clinicians to measure the actual usage of API functionality.
                    </P>
                    <P>A few commenters requested clarifications on whether any FHIR resources supported by CEHRT need to be counted. Commenters also recommended for ONC to isolate USCDI v1 FHIR resources that are within scope of § 170.315(g)(10) for reporting consistency across health IT developers. Several commenters recommended that this measure should not require tracking of FHIR resources that developers may support beyond USCDI v1, as required by § 170.315(g)(10).</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback on the burden associated with the 
                        <PRTPAGE P="1328"/>
                        measure. As discussed earlier in the preamble, to address burden, we have phased the implementation of the measures starting with a simpler version in the first year and then added the additional complexity in the subsequent years. Additionally, we have revised the measure to address burden. We agree with commenters that for reporting consistency and certain, clear requirements that the FHIR resources reported should align with the criterion § 170.315(g)(10). FHIR resources supported by and within the scope of the § 170.315(g)(10) criterion include FHIR resources referenced in the US Core IG attributed to and that support USCDI data elements. In this case, as an HTI-1 regulatory baseline, would be version 6.1.0 and v3, respectively, because data collection for this measure will begin after the technical requirements for health IT developers to update their certified health IT to these newer standards would have occurred as of January 1, 2026. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion. Additionally, if a health IT developer chooses to use the SVAP to adopt a newer version of standards referenced in § 170.315(g)(10), they will need to report based on the newer versions.
                    </P>
                    <P>
                        We also appreciate the requests for clarification on the metrics. Our intent is to measure the adoption and use of FHIR by industry users (
                        <E T="03">e.g.,</E>
                         third-party app developers, health IT developers, provider organizations). To clarify on whether the metric intends for developers to report the number of total resources returned for each resource, or the number of requests that returned at least one resource for each resource, we have revised the first metric to make it clear that we expect the latter. Additionally, we have removed the phrase, “in response to a call” across the metrics associated with the measure. For example, we have revised the metric from, number of FHIR resources returned/transferred in response to a call to certified API technology by FHIR resource type to the following, number of requests made to certified health IT that returned at least 1 FHIR resource by FHIR resource type. Both the proposed and revised metric assess the types of FHIR resources provided by certified health IT in response to a request. A request made to certified health IT can return a variety of different types and number of FHIR resources in response. The proposed metric focused on both the number of resources and types of resources returned; the revised metric focuses largely on the types of resources returned rather than the volume of resources returned. This simplified metric will still provide us with the necessary information on the types of resources provided. As noted by commenters, the total volume of FHIR resources returned is more difficult to interpret. The volume of resources could be related to a small number of apps returning a lot of data or many apps returning a little data. In contrast, the number of requests that returned at least 1 resource by resource type provides us insights into the “demand” for each resource and is easier to interpret. Measuring queries alone doesn't provide insight into whether data was shared in response to the query as there may not be data available to return. The goal in this metric is to understand the number of API requests that return various FHIR resources to gain insight on the resources most commonly exchanged.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A couple commenters requested specific clarification on whether the metric, number of distinct certified health IT deployments (across clients) is intended to be the total number of API deployments active at any time during the reporting period, or the total number active as of the end of the reporting period. The commenters recommended defining it to be the total number of API deployments active at any time during the reporting period. Another commenter noted a limited situation where an EHR user may have more than one production database of a certified solution and requested additional clarification for reporting on the measure, anticipating that they would count all deployments of the certified solution regardless of the number of clients that represents. A couple commenters provided qualitative ratings of burden associated with the metric, indicating that this would be low level of effort.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. Originally, we proposed reporting the number of distinct certified API technology deployments (across clients) during the reporting period. We clarify that this refers to counting the total number of certified health IT deployments active at any time during the reporting period, not the total number active as of the end of the reporting period. We had not intended, nor indicated, that we would be measuring this as of the end of the reporting period. We also acknowledge situations where an EHR user may have more than one production database of a certified solution and have revised the measure to count all deployments of the certified solution regardless of the number of clients that represents. The metric now measures the number of distinct certified health IT deployments (across clients) active at any time during the reporting period (overall) and by user type (
                        <E T="03">i.e.,</E>
                         patient-facing and non-patient-facing).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed support for patient-facing versus provider-facing stratification. One commenter expressed concern about reporting in this manner as endpoints can serve multiple and broad audiences. For example, the same endpoint could be used for both patients and providers. The same commenter recommended to report based on user type instead of endpoint types.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for their input and agree that FHIR endpoints are not necessarily specific to a user type and can serve multiple audiences. Given that endpoints can serve both patients and providers (for example) and thus would have to be double counted if that was the case, we have modified the metric to instead report the types of users the endpoint serves. We believe this will simplify reporting. Therefore, we have replaced the term endpoint type with user type. The user type categories are patient-facing and non-patient-facing. We believe the revision better represents our intention of understanding the user types that are using FHIR resources and FHIR APIs.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters were generally split on the proposed stratification of reporting both the FHIR version and the US Core Implementation Guide (IG) version. Those in support of stratifications indicated that the stratifications provide important distinctions for understanding the use and development of FHIR and is appropriately scoped in alignment with how most health IT developers' certified APIs are deployed. One commenter noted that being able to track IG conformance beyond US Core is essential to understanding how the industry is using FHIR and the data being exchanged via FHIR. Additionally, one commenter who supported the stratification noted that given continued updating of the US Core IG, future FHIR versions and US Core IG versions may not be synonymous in describing the capabilities of a technology, making it necessary to stratify by both FHIR version and the US Core IG version. One commenter recommended requiring the reporting of each FHIR resource by IG conformance beyond the US Core IG at 
                        <PRTPAGE P="1329"/>
                        the installation level for all health IT developers, including smaller developers that certify to FHIR API criteria. Several commenters suggested that ONC remove the stratifications for FHIR version and US Core IG version, noting that FHIR R4 is currently the only relevant version of FHIR base specification version and that, in most cases, health IT developers are only conformant to one version of the US Core IG. However, one commenter was supportive of the inclusion of the proposed stratifications for future reporting, as long as ONC provides specific guidance to health IT developers. One commenter noted that stratifying the number of deployments by the proposed stratification attributes does not make sense unless ONC's objective is to measure FHIR APIs or resources transferred and recommended stratifying deployments by the version of the certified health IT product. Another commenter highlighted that the proposed stratifications for FHIR version and US Core IG version would be a high level of effort and recommended limiting the measure stratifications to only patient-facing and non-patient facing endpoints.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We agree that the stratifications provide real-world data regarding the implementation and use of FHIR and US Core IG. This detailed reporting would help inform our goal of guiding future development of standards and insights on the current implementation and use of standards. We also acknowledge some support for restricting the measure specification to FHIR R4 and to one version of the US Core IG. In response to comments, we have made changes to metrics related to this measure so that the metrics are simplified and the stratification by FHIR version no longer needs to be reported. We also have developed a phased approach to implement the measure and related metrics over two years. Similar to the HTI-1 Proposed Rule metric, which called for reporting the number of FHIR resources returned/transferred in response to calls (also called requests) to a certified health IT by FHIR resource type, the first metric listed below also assesses the types of FHIR resources provided by certified health IT in response to a request. The revised metric no longer requires the number of FHIR resources, but instead requires counting the number of requests where at least one FHIR resource was provided. As described earlier, we sought to simplify this metric in response to comments and thus scaled back this metric to the number of requests made that returned at least 1 FHIR resource by resource type. For the second metric listed below, we have simply embedded the original stratification—by user type (which replaced type of endpoint)—within the metric; rather than listing the stratifications separately. The third metric differs from the second metric because it asks about the number of distinct certified health IT deployments (across clients) overall and by user type, and is not limited to those certified health IT deployments which were associated with at least one FHIR resource returned or transferred. We note that for the third metric, the word “total” was removed from the HTI-1 Proposed Rule measure as there is no substantive difference between “total number” of distinct certified health IT deployments (across clients) by user type (
                        <E T="03">i.e.,</E>
                         patient-facing and non-patient-facing) and “number” of distinct certified health IT deployments (across clients) by user type (
                        <E T="03">i.e.,</E>
                         patient-facing and non-patient-facing) and we seek to create consistency across the metrics.
                    </P>
                    <P>As noted earlier, to reduce burden, we have dropped the stratification by FHIR version but have kept the US Core IG version stratification. Given that we are aligning the reporting of FHIR resources to those supported by the § 170.315(g)(10) criterion and health IT developers will also report on the US Core IG version which aligns with the specific version of FHIR, we do not also need to separately obtain information on FHIR version. The metrics indicate the number of distinct certified health IT deployments (across clients) associated with at least one FHIR resource returned by US Core IG version(s). Together, the phasing of the reporting requirements and simplifying metrics (including removing the FHIR version stratification) will lower the initial reporting burden for health IT developers, as well as provide health IT developers additional time to develop the infrastructure necessary to report on the more advanced stratification (US Core IG versions) which would have valuable insights.</P>
                    <HD SOURCE="HD3">Finalization of Measure</HD>
                    <P>We have finalized the measure as “use of FHIR in apps through certified health IT” in § 170.407(a)(3)(iv). We have revised the proposed measure based on public comments received. Specific metrics to support this finalized measure are listed below and described further in the accompanying measure specification located on ONC's website. As noted earlier, if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion. The reporting period for the measure and related metrics below consists of one calendar year. Data collection for the measures and associated metrics will begin during the first and second phases of reporting (which is further described later in the preamble):</P>
                    <P>In the first year (where responses will be due July 2027, and annually thereafter), we require developers to report the:</P>
                    <P>• Number of requests made to distinct certified health IT deployments that returned at least 1 FHIR resource by FHIR resource type.</P>
                    <P>
                        • Number of distinct certified health IT deployments (across clients) associated with at least one FHIR resource returned, overall and by user type (
                        <E T="03">e.g.,</E>
                         patient-facing and non-patient-facing).
                    </P>
                    <P>
                        • Number of distinct certified health IT deployments (across clients) active at any time during the reporting period, overall and by user type (
                        <E T="03">i.e.,</E>
                         patient-facing and non-patient-facing).
                    </P>
                    <P>In year 2, in addition to what is required in year 1, we require developers to report the metrics below. These metrics will be due July 2028 (and annually thereafter):</P>
                    <P>• Number of distinct certified health IT deployments (across clients) associated with at least one FHIR resource returned by US Core Implementation Guide version.</P>
                    <HD SOURCE="HD3">Use of FHIR Bulk Data Access Through Certified Health IT Measure</HD>
                    <P>We proposed (88 FR 23840) to adopt the “use of FHIR bulk data access through certified health IT” measure in § 170.407(a)(6), which would measure the number of bulk data downloads completed through certified health IT relative to the number of certified health IT deployments or installations. Specifically, we stated that this measure would provide information on how certified health IT is being used to perform “read” services for a specified patient population using the HL7 FHIR® Bulk Data Access (Flat FHIR) V1.0.1 standard. A developer of certified health IT with Health IT Modules certified to the “standardized API for patient and population services” (§ 170.315(g)(10)) certification criterion would be required to report under this proposed measure.</P>
                    <P>
                        We proposed (88 FR 23840) the first numerator to be the number of data/download requests completed during the reporting period using certified health IT certified to the “standardized 
                        <PRTPAGE P="1330"/>
                        API for patient and population services” (§ 170.315(g)(10)) in response to a bulk data download request to export all data for patients within a specified group. We proposed (88 FR 23840) the second numerator to be the number of distinct certified health IT deployments or installations certified to the “standardized API for patient and population services” (§ 170.315(g)(10)) (across clients) that successfully completed at least one bulk data download request during the reporting period.
                    </P>
                    <P>
                        We proposed the denominator (88 FR 23840) to be the total number of distinct certified health IT deployments or installations (across clients). We requested comment on whether additional stratifications would provide valuable insights, what additional data developers of certified health IT are collecting, and what effort developers of certified health IT are devoting to collecting additional data such as: (1) intended use case (
                        <E T="03">e.g.,</E>
                         population analytics, reporting, research); (2) entity calling the API (
                        <E T="03">e.g.,</E>
                         healthcare organization, payer, public health agency); and (3) automated queries (refreshing the data at certain intervals) versus ad hoc queries. For future measure development, we requested comment on whether it is possible to collect information on the number of authorized users calling a bulk FHIR API, the level of effort required to collect this information, and whether it would provide valuable insights.
                    </P>
                    <P>
                        We also noted and clarified that non-standard or proprietary resources (
                        <E T="03">e.g.,</E>
                         non-FHIR based) transferred would be excluded from this measure, and that the proposed data for this measure would not include patient-facing applications, as individual patients only have the right to access their own records or records of patients to whom they are a personal representative.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters were supportive of the proposed measure. Two community healthcare associations supported this measure, expressing that this measure benefits community health centers by monitoring the ability to leverage comprehensive data for population health management and analytics, which will guide public health and population health initiatives. One commenter strongly recommended including at least one metric to track the real-world performance of current HL7/SMART FHIR bulk data implementations. One commenter expressed an opinion that the burdens of data capture for this reporting purpose outweighed the value of additional stratification and suggested starting with a “core” measure and layering on additional stratifications using a phased approach. The commenter noted that while reporting is feasible, it may require development to capture a specific countable event for reporting purposes. A couple of commenters also provided qualitative ratings of burden associated with the measure. One commenter indicated that the first numerator would be medium level of effort; whereas the other commenter indicated that the first numerator would be low level of effort. Both commenters indicated that the second numerator would be low level of effort, and that the denominator would be low level of effort.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support expressed by commenters as well as the desire to phase in the measure, providing more time to implement the measure which, overall, has relatively lower burden. We also appreciate the suggestion to include at least one reporting metric to track the real-world performance of current bulk FHIR implementations. However, this will require additional research to determine whether the reporting metric should be included for future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested additional clarity on whether the specification of “operationalized as [FHIR ServerBase]/Group/[groupid]/$export” is used for both numerators in this measure. Additionally, commenters expressed confusion on whether the count for both measures is defined as the number of group export completed or the number of group export completed, accessed, and downloaded. The commenters recommended to count the number of completed requests, regardless of whether they are subsequently accessed and downloaded by the requestor. One commenter noted that their health IT solution cannot determine when a user has downloaded all queried and retrieved data files. One commenter requested additional clarity on the difference between “requests completed” in the first numerator and “successfully completed” in the second numerator for a bulk data download request. Another commenter suggested defining “complete” as when the Bulk Data Status Request reports a status of complete (
                        <E T="03">i.e.,</E>
                         the timepoint when the user may begin downloading files). One commenter requested additional clarity on how “rate” will be measured under the second numerator. One commenter requested clarification regarding the requirement to include API-enable “read” services for multiple patients across all endpoints regardless of whether it is publicly available or not and specifically whether non-patient-facing endpoints are to be counted, since regulations only require patient-facing URL endpoints to be published. One commenter suggested for ONC to collect data on bulk FHIR data queries by cohort type (
                        <E T="03">e.g.,</E>
                         research, financial operations, care management, public health, electronic case reporting).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. To clarify, the bulk data download request using certified health IT to export all data for patients within a specified group will be operationalized as “[FHIR ServerBase]/Group/[groupid]/$export” for the metrics associated with this measure. We agree with commenters that the measure should focus on the number of completed requests, regardless of whether they are subsequently accessed and downloaded by the requestor and have revised the wording of both metrics to reflect this change. Thus, “completed” is defined as when the Bulk Data Status Request reports a status of complete (
                        <E T="03">i.e.,</E>
                         the timepoint when the user may begin downloading files). We believe there is not a substantive difference between “successfully completed” and “completed,” and to keep consistency between these metrics, we have removed the proposed term “successfully” from both metrics. We have also replaced the term “data/download” to “bulk data access” for consistency with the title of the measure.
                    </P>
                    <P>We have removed “expected metrics” that we had originally listed in the measure specifications sheets accompanying the HTI-1 Proposed Rule, such as the rate of bulk data download requests. To clarify, it is ONC that will be responsible for calculating derived statistics based upon the metrics and data the developers report. We will also determine how calculated metrics will be aggregated and reported (whether at the national, developer, and/or product level) once we receive the data. How the data is presented will depend in part upon the completeness and quality of the data received.</P>
                    <P>
                        These metrics apply to API-enabled “read” services for multiple patients where the number reported should reflect the “read” access queries that used the population services capabilities in § 170.315(g)(10) (
                        <E T="03">e.g.,</E>
                         the FHIR Bulk Data Access IG). Given that bulk FHIR is likely primarily for non-patient facing use cases, it should not be limited to patient-facing endpoints; it needs to include “all” endpoints and use cases. Furthermore, these metrics are unrelated to the API Condition of Certification requirements for publishing patient-facing endpoints, 
                        <PRTPAGE P="1331"/>
                        which supports patient access to their data using 3rd party apps and not related to Bulk FHIR. To reiterate, the metrics should reflect activity across all endpoints regardless of whether publicly available or not and type of endpoint user. The endpoints included should not be limited to those only used by patients. This is important as we seek insight on bulk data usage volume independent of user type and have developed a measure in a manner that does not differentiate between public and private APIs. In addition, we note that the measure applies to FHIR Bulk Data requests for FHIR resources that within the scope of § 170.315(g)(10) as discussed in more detail in the responses to comments in the previous measure above. 
                    </P>
                    <P>We appreciate the interest expressed in a reporting metrics that measure the adoption and conformance of FHIR Bulk Data APIs by cohort type or use case and may explore the feasibility of this in the future.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended ONC to align the denominator to the “use of FHIR in apps supported by certified API technology” measure. Another commenter requested clarification on whether the denominator is intended to be the total number of API deployments active at any time during the reporting period, or the total number active as of the end of the reporting period and recommended to define the denominator to be the total number of API deployments active at any time during the reporting period. Another commenter noted a limited situation where an EHR user may have more than one production database of a certified solution and recommended to count all deployments of the certified solution regardless of the number of clients that represents.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. In response to comments, we have reviewed the metrics (previously referred to as denominators) for the two measures (“use of FHIR in apps supported by certified API technology” [finalized as “use of FHIR in apps through certified health IT”] and “use of FHIR bulk data access through certified health IT”). We concur that these metrics should be consistent with each other and measure the number of distinct health IT deployments (across clients) active at any time during the reporting period. Therefore, we will use the metric from the “use of FHIR in apps through certified health IT” measure for calculating any derived statistics.
                    </P>
                    <P>We acknowledge situations where an EHR user may have more than one production database of a certified solution and clarify that this measure counts all deployments of the certified solution regardless of the number of clients that represents.</P>
                    <HD SOURCE="HD3">Finalization of Measure</HD>
                    <P>We have finalized the “use of FHIR bulk data access through certified health IT” measure in § 170.407(a)(3)(v). We have revised the proposed measure based on public comments received. Specific metrics to support this finalized measure are listed below and described further in the accompanying measure specification located on ONC's website. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion:</P>
                    <P>1. Number of bulk data access requests completed (across clients) to export all data requested for patients within a specified group.</P>
                    <P>2. Number of distinct deployments of the certified health IT deployments (across clients) that completed at least one bulk data access request.</P>
                    <P>The reporting period for the measure and related metrics above consists of one calendar year. Data collection for the measures and associated metrics will begin during the second phase of reporting (which is described later in the preamble).</P>
                    <HD SOURCE="HD3">Electronic Health Information Export Through Certified Health IT Measure</HD>
                    <P>We proposed (88 FR 23841) to adopt the “electronic health information export through certified health IT” measure in § 170.407(a)(7) which would capture the use of certified health IT to export single patient and patient population EHI. A developer of certified health IT with Health IT Modules certified to the “electronic health information (EHI) export” (§ 170.315(b)(10)) certification criterion will be required to report data under this proposed measure.</P>
                    <P>We proposed (88 FR 23841) a count for this measure (rather than a numerator and denominator) that includes the number of full data EHI exports requests processed during the reporting period and reported by the following subgroups: (1) by a single patient EHI export; and (2) by patient population EHI export. We also proposed (88 FR 23841) reports should include a “yes” or “no” attestation for enabling direct-to-individual EHI exports. We stated that the proposed measure would report on the number of EHI export requests processed by a health IT developer and provide insights on the implementation of the EHI export capability. We refer readers to the HTI-1 Proposed Rule for detailed background on the measure (88 FR 23841).</P>
                    <P>
                        As stated in the HTI-1 Proposed Rule (88 FR 23841), we also noted in the ONC Cures Act Final Rule (85 FR 25695) that the EHI Export certification criterion in § 170.315(b)(10) does not require “direct-to-patient” functionality in order for a developer to demonstrate conformance to the criterion. However, we did not preclude this functionality, and we sought comment as part of the HTI-1 Proposed Rule on whether any products support direct-to-patient EHI Export functionality to inform future policy decisions. We also sought comment on whether it would be valuable for this measure to be reported by “use case” for why the data was exported (
                        <E T="03">e.g.,</E>
                         moving to another certified health IT system, use for a population health tool), and how feasible would it be for impacted developers to report in this manner. Lastly, we sought comment on whether it would be valuable, and if so, how valuable, for this measure to include reports regarding the types of recipients (
                        <E T="03">e.g.,</E>
                         patients, organizations) of the exported data, and how feasible would it be for impacted developers to report this data in this manner.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Most commenters expressed support of this measure with numerous commenters indicating that this measure is feasible as written and that the burden to report this measure is low. One commenter recommended delay or removal of this measure though did not provide a rationale. One commenter recommended ONC to consider how patient EHI can be best protected upon export, given concern regarding inappropriate use of information. Another commenter recommended creation of patient-facing and provider-facing educational materials in support of this measure. One commenter asked for clarity regarding the term “processed” and whether it intended to indicate started or completed. One commenter disagreed with an attestation reporting requirement for functionality that is not required. One commenter who supported attestation asked for clarification on “direct-to-individual,” specifying whether the capability should be performed by the patient without any health care provider involvement. One commenter indicated that capturing and reporting “use case” does not provide value and did not support this capability while requesting that the “use case” and “recipient” 
                        <PRTPAGE P="1332"/>
                        types be standardized across all health IT developers. One commenter requested clarification of the definition of a “full data export” and whether a subset of data in a timeframe or based upon patient request would constitute “full data” in the context of this measure.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support expressed by numerous commenters, as well as the thoughtful feedback and suggestions for this measure. However, in our overall efforts to reduce burden, we have not adopted the “electronic health information export through certified health IT” measure. We plan to revisit the EHI export capability in § 170.315(b)(10) as a potential measure when this capability is more widely deployed and may propose measures that provide more valuable insights in future rulemaking.
                    </P>
                    <HD SOURCE="HD3">Measurement Area: Public Health Information Exchange</HD>
                    <P>
                        In the HTI-1 Proposed Rule (88 FR 23841), we discussed how the COVID-19 pandemic exposed many gaps and challenges in the nation's public health infrastructure, including a need for more accurate and timely data, increased electronic exchange of patient health information between health care providers and public health agencies, and greater support for vulnerable individuals and communities disproportionally affected by the pandemic.
                        <SU>208</SU>
                        <FTREF/>
                         Therefore, in § 170.407(a)(8) and (9), we proposed two measures within the “public health information exchange” area for reporting health care providers' use of certified health IT to exchange data with an immunization information system (IIS) (88 FR 23841). We stated that the insights from these measures could help ONC (and HHS more broadly) assess the public health capabilities of certified health IT, and that we believe that more detailed measurement of health care providers' ability to use certified health IT to successfully exchange health information with public health agencies would provide critical data for pandemic response and other public health emergencies.
                    </P>
                    <FTNT>
                        <P>
                            <SU>208</SU>
                             Dixon BE, Rahurkar S, Apathy NC. Interoperability and health information exchange for public health. In Public health Informatics and information systems 2020 (pp. 307-324). Springer, Cham. 
                            <E T="03">https://doi-org.ezproxyhhs.nihlibrary.nih.gov/10.1007/978-3-030-41215-9_18.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         We received broad support for the adoption of two measures within the “public health information exchange” area. These commenters also encouraged additional public health information exchange measures in future iterations of the Insights Conditions, such as for cancer reporting, electronic case reporting, syndromic surveillance, and electronic laboratory reporting, along with an estimated timeframe for the development and implementation of these measures. A couple of commenters recommended that ONC align future public health information exchange measures with CMS measures. One commenter expressed support and requested clarity on how the information will be used to evaluate performance, or inform policy or other decision making. Another commenter requested ONC to make aggregate responses available to the public.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support and agree that the goal is to help measure progress related to certified health IT's ability to support public health information exchange. This data will provide “insights” into health care providers' use of certified health IT for public health information exchange that can guide policy efforts to improve these efforts through initiatives such as the CDC Data Modernization Initiative. In this iteration of the Insights Condition, we have focused on immunization related exchange. However, in future rounds, we plan to consider other areas of public health information exchange to include as part of the Program, working with CMS, CDC, and other federal partners as necessary to ensure alignment of measures. As noted in the HTI-1 Proposed Rule (88 FR 23847), we plan to make the measures and the required data documentation reported by health IT developers available to the public.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern on the level of burden required by health IT developers to obtain the necessary data for each measure and recommended requiring only overall administration submission numbers. Another commenter opined on whether engaging with public health agencies to generate some meaningful data might be less burdensome on vendors and their users and may paint a more complete picture of the situation.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We understand the concerns expressed regarding burden and recognize that these measures may require discrete effort on the part of health IT developers. We appreciate the feedback from commenters and made revisions to reduce the burden associated with creating and reporting these measures which are further detailed below in this section of the preamble. This includes removing our proposal to report by age for the “immunization history and forecast” measure, providing additional time for implementation by phasing in the measures over two years, and phasing in complex aspects of the requirements (
                        <E T="03">e.g.,</E>
                         reporting by age and/or IIS) over a span of three years.
                    </P>
                    <P>Data from the measures we have finalized in this final rule will provide insights into the level of exchange between certified health IT systems and IISs, to identify opportunities to address gaps or lags discovered. With regards to public health entities having similar measures, the CDC's Immunization Integration Program (IIP) Testing and Recognition initiative, an ONC approved alternative testing method for the “transmission to immunization registries” (§ 170.315(f)(1)) criterion, share some similarities to the measures we had proposed and subsequently finalized. We seek to build upon the IIP by expanding the scope of their measures, which cover a sample of jurisdictions, to include all jurisdictions. This expansion would provide national level insights. In contrast to the IIP, ONC's electronic submission of immunization administrations to IISs shall be reported by age categories, which will help interpret the data as IISs are more likely to have mandates for reporting vaccinations given to children and adolescents compared to adults. We also have a unique measure in comparison to the IIP, which measures the total number of vaccine administrations. Developers that participate in the IIP should gain experience that will help them with reporting for the Insights Condition. Regarding the concern whether public health jurisdictions may serve as an alternative source for this data, while an IIS serves as a valuable source to understand vaccination coverage using unique patient records and vaccination histories, not all jurisdictions have access to or the ability to produce the measures that we proposed. Jurisdictions with high performing IISs and staff to support them are more likely to have these data and use them to improve data quality. However, not all jurisdictions have access to these data. Thus, the measures address an important gap in information that can help improve interoperability between health care providers and jurisdictional IISs.</P>
                    <HD SOURCE="HD3">Immunization Administrations Electronically Submitted to Immunization Information Systems Through Certified Health IT Measure</HD>
                    <P>
                        In the HTI-1 Proposed Rule (88 FR 23842), we proposed to adopt in § 170.407(a)(8) a public health exchange measure that would report on the volume of immunization administrations electronically submitted 
                        <PRTPAGE P="1333"/>
                        to an immunization information system through certified health IT. We stated that this measure would capture the use of certified health IT to send information on vaccination and immunization administrations to an IIS. Specifically, the proposed “immunization administrations electronically submitted to an immunization information system through certified health IT” measure would require developers of certified health IT with Health IT Modules certified to the “transmission to immunization registries” (§ 170.315(f)(1)) criterion to report on the number of records of immunizations administered that were sent electronically to an IIS during the reporting period. We proposed that developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) that do not have users that administered immunizations during the reporting period would attest that they are unable to report on this measure.
                    </P>
                    <P>We stated that the intent of the measure is to ensure that ONC has the information necessary to assess whether Health IT Modules certified to § 170.315(f)(1) are being used to support electronically sending vaccination information data to IISs, which has proven to be critical to public health preparedness and response.</P>
                    <P>
                        For the numerator, we proposed (88 FR 23842) developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) report the number of immunization administrations from which the information was electronically submitted to an IIS successfully during the reporting period by IIS and age group. We proposed (88 FR 23842) that the numerator and denominator counts would be reported overall (across IIS and age subgroups) and by the following subgroups: (1) number of administrations by IIS; and (2) number of administrations by IIS and age group (adults (18 years and over) and children/infants (17 years and under)). We defined a successful submission to an IIS would be the total number of messages submitted minus acknowledgments with errors (2.5.1, severity level of E). We stated that we believe this definition will avoid limitations from IIS jurisdictions that do not send HL7 Acknowledgment messages (ACKs) for this measure. Given that, we proposed that ACKs with an error (severity level of E) 
                        <SU>209</SU>
                        <FTREF/>
                         would not be counted, and we sought comment on whether ACKs with a warning (severity level W) should still be counted in the numerator. We also sought comment (88 FR 23842) on whether the number of immunizations administered can be linked to immunizations submitted to the IIS, effectively creating a subset of the numerator (immunizations administered). Additionally, we sought comment (88 FR 23842) on whether a successful submission should be counted if a health care provider is able to successfully submit to at least one registry, as opposed to all the registries they submitted to (
                        <E T="03">e.g.,</E>
                         health care providers who operate in multiple states sending data for the same administration to multiple IISs). In the Proposed Rule (88 FR 23842), we also considered whether “replays,” which involve resubmitting administrations until they are successfully submitted, qualify as a successful submission. In other words, we sought comment on whether successful submissions should be limited to the first attempt to submit.
                    </P>
                    <FTNT>
                        <P>
                            <SU>209</SU>
                             HL7 Version 2.5.1. Implementation Guide for Immunization Messaging. Release 1.5. October 1, 2014. 
                            <E T="03">https://www.cdc.gov/vaccines/programs/iis/technical-guidance/downloads/hl7guide-1-5-2014-11.pdf.</E>
                        </P>
                    </FTNT>
                    <P>We proposed (88 FR 23842) the denominator for this measure to be the number of immunizations administered during the reporting period, and that the denominator be stratified by the following subgroups: (1) number of administrations reported to each IIS; and (2) number of administrations reported to each IIS, by age group (adults (18 years and over) and children/infants (17 years and under)). Given the variation in immunization reporting requirements and patient consent by state or jurisdiction, reporting of administrations by IIS is critical to interpreting the data correctly, therefore we proposed this measure to be stratified by IIS. In addition, given that immunization requirements are different for children and adults, we proposed stratifying by age group as well. To further inform public health exchange efforts, we also sought comment (88 FR 23842) on whether adolescents/infants should be further stratified by age, and by what age limits. For providers who operate in multiple states, and thus would be sending data for the same administration to multiple IIS, we sought comment (88 FR 23842) on whether a successful submission should be counted if a provider is able to successfully submit to at least one registry versus all the registries to which the provider submitted. As stated in the HTI-1 Proposed Rule (88 FR 23843), the data collected for this measure would enable ONC to calculate the percent of immunizations administered where the information was electronically submitted to an IIS.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters supported the proposed “immunization administrations electronically submitted to an immunization information system through certified health IT” measure, stating that these reporting metrics will encourage providers to institute proven best practices for obtaining consent and report vaccinations where consent is received. Commenters also stated that organizations using certified health IT would benefit, as it would provide aggregate numbers and user-friendly reports, and help detect connectivity interruptions, as well as help federal agencies, public health agencies, and health IT developers better understand the extent to which health IT is exchanging data with an IIS. A commenter also stated that this would provide real-time and comprehensive data on immunization coverage, facilitating targeted interventions, and contribute to overall population health protection. One commenter recommended that ONC and CMS continue collaborating to consider how their measures can be analyzed and interpreted in tandem to answer questions about data exchange, as well as to collaborate on additional future public health measures.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support of the measure and agree with the potential benefits of a measure that assesses how Health IT Modules certified to the “transmission to immunization registries” (§ 170.315(f)(1)) criterion are being used to support electronically sending vaccination information data to an IIS. This criterion has proven to be critical to public health preparedness and response. We believe this measure can provide insights beyond current physician surveys limited by small sample size that do not provide information on actual usage of functionality that supports electronically sending vaccination data to an IIS.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concern regarding the burden related to this measure. Commenters representing health IT developers recommended we delay the patient age and IIS stratifications from the measure and proceed with the overall administration submission numbers, due to the high burden level rating for these stratifications. Other commenters expressed support on the age group stratifications as proposed and did not believe any additional age group stratifications were necessary, stating that it may add unnecessary complexity 
                        <PRTPAGE P="1334"/>
                        to the measure. One commenter suggested eliminating the measure. Another commenter stated that since API access can be measured at either endpoint of the transaction, ONC should request this information from the IIS rather than from providers. One commenter recommended to lessen the burden, ONC could provide standardized value sets for use by all vendors in the counting of mandatory immunization requirements across the nation, however, the commenter conveyed that the necessary work for this effort would outweigh the benefits.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support expressed on the stratifications and have finalized the IIS and age stratifications as proposed. The IIS stratification is critical for assessing both the interoperability and exchange of information between certified health IT and immunization information systems as well as the extent to which health care providers are engaging in immunization reporting. Examining these data by IIS will allow us to monitor the evolving state of immunization data exchange as efforts are made to modernize public health information technology. Additionally, public health jurisdictions will obtain data which they currently don't have access to, and understand the extent to which certified health technology is used for immunization reporting. Therefore, we have kept the proposed IIS stratification. We also believe stratifying by age is important for the purpose of interpreting the results. Public health jurisdictions commonly mandate immunization reporting for children, but do so less for adults. Without the age stratification, it would be difficult to assess whether high or low rates of submission were due to differences in requirements related to adults versus children or another reason (
                        <E T="03">e.g.,</E>
                         issues with exchange between certified health IT systems and IIS). Thus, we kept the proposed stratification for age to provide insights on trends related to reporting immunizations for adults and children.
                    </P>
                    <P>However, we also understand and acknowledge the concerns expressed for the resources required to develop stratifications for this measure. In response to commenters, we have updated the implementation timelines to provide additional time for compliance by phasing in the stratifications (IIS and age) by an additional year and refer readers to the Insights Conditions and Maintenance of Certification section (III.F.3) for a detailed discussion of timelines and the phasing in of measures in this final rule.</P>
                    <P>We appreciate the comment inquiring about the potential role to leverage public health APIs to support measurement. The measure focuses on data submitted via certified health IT and note that the suggested use of public health APIs for measurement is currently outside the scope of the Program, and not all public health entities may have APIs to support this type of measurement.</P>
                    <P>We also clarify that the measure does not require logic customized to individual jurisdiction reporting mandates. As noted in the HTI-1 Proposed Rule (88 FR 23842) the number of immunizations transmitted to an IIS will reflect the provider organization's existing practices to transmit this data in accordance with jurisdictional requirements. Therefore, we do not see an immediate need to create a value set that would express those requirements. However, we may explore this suggestion in the future rulemaking to reduce burden.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested clarification on whether the age to be used for counting purposes is the age at the time of immunization administration or at the time the information is transmitted to the IIS. Another commenter recommended that adolescent data extend through age 18, rather than to age 18, to align with the Vaccines for Children program age ranges, as well as requested expectations for jurisdictions that either have limited adult reporting or have an adult “opt-in” model, as these jurisdictions will likely have a low level of reporting.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. In response to comments, we have modified the age categories for clarity. In alignment with the CDC's Vaccines for Children program, we have modified the age stratifications to the following two categories: (1) immunizations administered for patients 18 years of age and younger (children and adolescents) and (2) immunizations administered for patients 19 years of age and older (adults). We are aware that age-related requirements vary by jurisdiction but for the purposes of standardization and ease of reporting, we have opted to align our requirements with the CDC's Vaccine for Children Program. Patients in the measure's metrics should be counted based on age at time of administration. We acknowledge that a relatively small number of patients may fall into separate counts if the date of immunization is close to the end of the reporting period, but we expect that these instances should not significantly impact the metrics calculated.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended that timeliness should be added to this measure's numerator and stratify the measure by the definition of “timely” to be less than or equal to 24 hours to provide health IT developers, providers, and public health agencies with insights into how rapidly immunization data is being shared with IIS registries and accessed by health agencies.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the recommendation to factor timeliness and agree this plays a critical role in data quality and utility. We may consider this aspect for future potential measure enhancements as we seek to appropriately factor variation in provider workflow and jurisdictional reporting requirements.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested clarification on whether a message is a failure or success if the initial message for a vaccination administration is successful, but the administration is updated in the EHR, and the update message fails. One commenter suggested collecting how many submissions needed to be repeated. Several commenters stated that replays should qualify as a successful submission since there are scenarios that could create a submission failure at no fault of the developer, and immunization submitters should be recognized for successful error remediation. One commenter recommended that “replays” are considered successful submissions, but each replay of a single immunization administration should not be counted as a separate submission, as overcounting may result in inflating the numerator of the measure.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. The intent of the measure is to understand the process of submitting immunization to an IIS and efforts by health care providers to successfully submit immunization administrations to an IIS. While the process and effort can involve resolving message failures, the measure counts the number of immunizations administered that are submitted to the IIS, rather than the number of attempts to successfully transmit the immunization. With this in mind, we clarify that, in the instance where the initial message for an immunization administration is successful and a subsequent update in the EHR has an update message that fails, the metrics for the number of immunizations administered that were electronically submitted successfully to IISs overall, by age category and IIS should reflect the final status of the immunization submission to the IIS. There should not be two counts in these metrics for the successful initial 
                        <PRTPAGE P="1335"/>
                        message and the subsequent failure update message. We expect that the shift to calendar year reporting will minimize instances where the final status of successful vaccine submissions would not be available to count in the measure. Therefore, the measure will count the status of the final submission at the time the reporting period ends in these metrics, rather than counting each attempt separately. This applies to replays, which should not count as separate submission attempts in these metrics. Although this measure will not separately document the number of replays, we agree with commenters who supported counting replays and multiple messages as separate attempts to successfully submit an immunization and may consider future measures that would document the level of effort taken for successful error remediation. We encourage those reporting on this measure to include counts of replays in the supplemental documentation as this could shape future iterations of this measure.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed support that those acknowledgements with a severity level of “E” be considered a failure for purposes of the measure's numerator. The commenters added that acknowledgements with the severity level “W” should not be considered a failure, given that they were likely successfully processed by the IIS and their data accepted by the immunization program. However, another commenter noted the possibility that including acknowledgements with the severity level “W” could inflate the measure and make interpretation challenging. One commenter requested confirmation that only “E” responses should be subtracted from the success acknowledgements and noted it would be helpful for ONC to define the concepts of error and warning responses in the context of this measure. One commenter stated that there is variation on how the error status of level “E” is used in practices, noting that this would likely make the aggregated data ONC proposes to report less than accurate, and requested clarification on whether the purpose of the use of error and warning messages in this context is to assess whether immunization registries are functioning effectively. One commenter recommended that the successful submission definition be revised to reflect that no negative acknowledgement is a successful submission, until an alternative mechanism is used to route acknowledgements from the registry back to the EHR.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We appreciate the comment that acknowledgements from IIS with a severity level of “W” could potentially inflate the measure and acknowledges the variation on how “E” is used in practices. We intend to collaborate with the community to monitor how these instances may impact the interpretation of the measure and determine if it should be revised in the future. We also appreciate commenters requesting confirmation that the measure should consider acknowledgements with a severity level of “E” as a failed message. We confirm that this is the only severity level for messages that should be excluded from the measure's metrics for the number of immunizations administered that were electronically submitted successfully to IISs overall, by age category and IIS. We thank commenters for their consideration of the implications for error status level “E.” We confirm that successful submissions are defined as the total number of messages submitted to an IIS, minus acknowledgements with errors (2.5.1, severity level “E”). For these metrics, we clarify that not all immunizations that are administered and submitted during the period may receive a status of the submission acknowledgement message from an IIS during the reporting period. In this situation (where an acknowledgement from an IIS is not received), the immunization submission should be counted as successful. We request that health IT developers report the number of submissions that did not receive acknowledgement in the supplemental documentation so these metrics can be refined in the future if needed.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters stated that a successful submission should be counted if a health care provider is able to successfully submit to all of the registries to which the provider submitted, including submissions to more than one IIS, stating that the inflation of the count would be minimal.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In response to comments, the metrics for the number of immunizations administered that were electronically submitted successfully to IISs overall, by age category and IIS, indicate that each successful submission to an IIS to which a provider submits immunizations should be included and counted as a successful submission. Thus, an immunization that is successfully submitted to more than one IIS would be counted the number of times it was successfully submitted to each IIS. When the stratified metric is reported by IIS, the count inflation should not be an issue as the multiple submissions would be separated by IIS.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested clarification on the denominator counts. One commenter requested clarification on whether a patient who opts out of having certain administered immunizations submitted to the IIS should be included in the denominator, as well as if an immunization is ordered but refused by the patient. The same commenter also requested clarification on whether the denominator includes administered vaccines from provider organizations that do not yet have connectivity in place to an IIS for reporting administered vaccines. One commenter recommended that the denominator exclude the number of patients who have opted out of vaccination reporting to capture more accurately the proportion of immunization administrations electronically submitted.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their request for clarification. We clarify that the measure focuses on counting immunizations administered and submitted. Patients who have been administered an immunization and opt out of submitting their data to an IIS should count in the metrics for the number of immunizations administered overall, by age category and IIS, but not the metrics for the number of immunizations administered that were electronically submitted successfully to IISs overall, by age category and IIS. To ease burden and given the assumption that the number of opt-outs are relatively low, we believe it is sufficient to include them. However, there may be value in counting the number of opt-outs in the future to determine whether it is worth removing them (or separately report on these). Patients who decline an immunization will not appear in the metrics for the number of immunizations administered overall, by age category and IIS, and there will be no immunization submission to count in the metrics for the number of immunizations administered that were electronically submitted successfully to IISs overall, by age category and IIS. We also clarify that immunizations administered at health care provider organizations that have certified health IT eligible for reporting but do not have an existing, active connection to electronically submit immunizations to an IIS will count in the metrics for the number of immunizations administered overall, by age category and IIS, while there will be no count in the metrics for the number of immunizations administered that were electronically submitted successfully to IISs overall, by age category and IIS. This approach 
                        <PRTPAGE P="1336"/>
                        will contribute to insights on the number of immunizations that could be electronically submitted to reduce provider burden associated with manual submission.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that stratifying the denominator (number of immunizations administered within the reporting period) by IIS does not make sense since an IIS is not identified with an immunization administration. One commenter expressed concern stating that an EHR is unlikely to know of administrations reported to an IIS through a web portal or alternate mechanism and recommended that the measure should instead be out of the total number of doses administered how many doses were submitted electronically, and of those electronically submitted, how many were successful. A couple of commenters recommended that the number of administrations reported to each IIS should be revised to number of administrations valid for reporting to each IIS to ensure that the count of doses sent electronically only include those doses tagged as newly administered. Another commenter requested guidance on how doses should be counted in the metrics if two EHR systems merge, and another requested clarification on how data submitted from a non-traditional location should be counted.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The metrics for the number of immunizations administered overall, age category and IIS, is stratified or reported by IIS because we seek to assess the extent to which an IIS is receiving data on immunizations administered. While the location of the patient typically determines the IIS to which vaccine administration information is sent, given that it is unclear as to which data sources may be easily accessible to make this determination, we provide two options regarding how best to select the IIS for those vaccines that are administered but not submitted: (1) based upon the primary IIS used by the client site; or (2) based upon the jurisdiction associated with the client site's location. Whatever approach is used should be documented in the required documentation for this measure. We note that the stratification by age in the total vaccines administered within the reporting period enables comparisons with the vaccines submitted electronically metric.
                    </P>
                    <P>We clarify that the measure pertains to immunizations electronically submitted to IISs through certified health IT. Immunizations submitted via web portals or alternate mechanisms, such as manual submission of spreadsheets, would not be reported in the immunizations submitted electronically metrics, but, given that these were administered but not electronically submitted via certified health IT, they would be included in the metrics for the number of immunizations administered overall, age category and IIS. We do not believe it is feasible to remove these from the total vaccines administered metrics; however, if available, the volume of immunizations could be noted in the health IT developer's supplemental reporting to provide additional insight and context.</P>
                    <P>We also appreciate the requests for clarification on whether doses tagged as newly administered are included. We acknowledge that the “transmission to immunization registries” (§ 170.315(f)(1)) criterion includes historical vaccines and newly administered vaccines, giving health IT developers that certify to this criterion the capability to report both. We note this treatment of historical vaccines administered applies to data migrated from one EHR to another, and vaccines that were previously administered by another provider site. Because the proposed measure referred to administered immunizations (and not historical specifically), we clarify that the finalized measure will only count immunizations newly administered during the reporting period and will not count historical vaccines previously administered that were recorded during the reporting period. The inclusion of historical vaccines in addition to newly administered vaccines within one measure would be difficult to interpret; in the future we may consider the inclusion of historical vaccines based upon industry experience and the input we have received. The measure is not constrained to the type of health care provider who administered the vaccine or the location the vaccine was administered, provided the certified health IT is eligible for reporting.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested clarification whether the immunization administration would have to be within the reporting period or the IIS submission in the reporting period (or both).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         For the metric, immunizations administered that were electronically submitted successfully to IISs, immunizations should be both administered and submitted during the reporting period. An immunization administered outside the reporting period but submitted during the reporting period would not count for these metrics. We note that if no acknowledgment is received for immunizations administered, and submitted during the reporting period, then the immunization would count as successfully submitted.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested clarification on whether health IT vendors will be required to calculate a percentage and if so, requested ONC provide explicit guidance on the calculation components.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We clarify that ONC will be responsible for calculating percentages based on the counts that health IT developers submit.
                    </P>
                    <HD SOURCE="HD3">Finalization of Measure</HD>
                    <P>We have finalized the measure as “immunization administrations electronically submitted to immunization information systems through certified health IT” in § 170.407(a)(3)(vi). We have revised the proposed measure based on public comments received. Specific metrics to support this finalized measure are listed below and described in the accompanying measure specification located on ONC's website. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion. The reporting period for the measure and related metrics below consists of one calendar year. Data collection for the measures and associated metrics will begin during the first and second phases of reporting (which is described later in the preamble):</P>
                    <P>1. Number of immunizations administered overall (year 1),</P>
                    <P>2. Number of immunizations administered overall by IIS and age category (year 2).</P>
                    <P>3. Number of immunizations administered that were electronically submitted successfully to IISs overall (year 1),</P>
                    <P>4. Number of immunizations administered that were electronically submitted successfully to IISs overall, by IIS and age category (year 2).</P>
                    <HD SOURCE="HD3">Immunization History and Forecasts Through Certified Health IT Measure</HD>
                    <P>
                        In the HTI-1 Proposed Rule, in § 170.407(a)(9), we proposed to adopt a public health information exchange measure to require reporting on the number and percentage of IIS queries made per individual with an encounter (88 FR 23843). The “immunization history and forecasts” measure would capture the use of certified health IT to query information from an IIS under the “transmission to immunization 
                        <PRTPAGE P="1337"/>
                        registries” (§ 170.315(f)(1)) criterion. Therefore, we proposed (88 FR 23843) that developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) would be required to report for this measure. We emphasized that understanding whether health care providers are engaging in electronically querying immunization information from IIS is critical to public health preparedness.
                    </P>
                    <P>For the numerator, we proposed (88 FR 23843) developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) report the number of query responses received successfully from an IIS overall and by subgroup, by IIS and age group (adults (18 years and over) and children/infants (17 years and younger)) during the reporting period. The definition of a successful response from an IIS should be the total number of messages submitted minus acknowledgments with errors (2.5.1, severity level of E). However, since HL7 Z42 messages contain both immunization history and forecast, whereas Z32 messages exclusively contain history, we sought comment (88 FR 23843) on whether both message types should be included in the measure numerator.</P>
                    <P>As stated in the HTI-1 Proposed Rule (88 FR 23843), the first denominator we proposed for this measure would be the total number of immunization queries overall and by subgroup, by IIS and age group (adults (18 years and over) and children/infants (17 years and younger)) during the reporting period. We proposed to add this denominator to the measure proposed by the Urban Institute to provide data on the total number of query responses that are and are not successfully received from an IIS, as this will give further insights into any potential technical challenges that may be occurring during query exchange. The second denominator we proposed for this measure would be the total number of encounters overall and by subgroup during the reporting period. However, since it is unlikely that queries happen for every patient encounter, we sought comment (88 FR 23843) on whether the second denominator should capture to total number of applicable patient encounters during the reporting period regardless of whether a query was sent to an IIS. We proposed (88 FR 23843) that the numerator and denominator counts would be reported overall (across IIS and age subgroups) during the reporting period and by the number of IIS queries made by IIS and age group (adults (18 years and over) and children/infants (17 years and younger) during the reporting period. In the HTI-1 Proposed Rule (88 FR 23843), we conveyed our belief that reporting by these subgroups would be necessary to interpret the data and create public awareness that could inform IISs and other public health participants about the progress being made in immunization data exchange. We sought comment (88 FR 23843) on whether children/infants should be further divided and by what age limits.</P>
                    <P>We also proposed (88 FR 23843) developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) would attest that they are unable to report on this measure if they have no users that administered immunizations during the reporting period. There may also be providers who do not administer immunizations but would want to query an IIS to determine whether their patient has received a vaccination. We sought comments (88 FR 23843) on whether we should include this exclusion or suggestions on how we could better refine it.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters expressed support for the proposed measure, stating that comprehensive immunization history and forecasts through certified health IT enables health care providers to proactively manage immunization programs and promote preventative care. Also, by utilizing certified health IT to track history and generate forecasts, health care providers can identify immunization gaps, schedule timely vaccinations, and implement outreach initiatives to increase vaccination rates.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support of the proposed measure and appreciate the examples of how the measure would support improvements in preventive care for patients. We agree that this measure, which provides insights on how certified health IT is used to support health care providers to electronically query immunization information from IIS, is critical to public health preparedness.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern with the second denominator, stating that the total number of visits will not accurately reflect the number of immunization query messages expected to be generated, as not all encounters can reasonably be expected to result in a query message, and suggested an alternate measure to include a numerator defined as the total number of unique individuals queried for during the reporting period and a denominator defined as the total number of unique individuals with encounters during the reporting period. Another commenter recommended that ONC develop a simpler definition of encounters that developers can apply to their own systems and encounter classification structures or establish a clear set of encounter type categories with fully defined mapping such as OMB/CDC Race categories/details. The same commenter suggested ONC coordinate with CMS to ensure that the value set references include all SNOMED and CPT codes in the proposal or identified alternatives. One commenter recommended modifying the second denominator to include encounters with immunizing provider sites rather than all encounters.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We concur that not all encounters can be expected to generate a query to an IIS. Therefore, as one commenter noted, the number of visits may not reflect the number of immunization queries expected. We may collaborate with the community to consider the measure of unique patients for whom queries were made to the IIS for future rulemaking. The measure does not include encounter-based metric from the immunization measure domain to address the concern raised by commenters that not all encounters can be expected to result in a query message. We will still receive counts of the number of unique patients with an encounter during the reporting period, as proposed (and finalized) in the “consolidated clinical document architecture (C-CDA) problems, medications, and allergies reconciliation and incorporation through certified health IT” measure. We refer readers to the definition of terms section immediately following this section for a more detailed discussion on defining encounters.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters expressed concern with the intent and interpretation of the proposed measure. One commenter stated that if the intent is to assess the overall functioning of bidirectional query, ONC should clarify this intent such that a low ratio does not reflect poorly on the developer of certified health IT or the querying organizations. One commenter commented that it was their experience that some IISs are not ready to return the data for response to the query and noted that this would impact the countable events for this measure and should be publicly disclosed if/when the data is published. One commenter recommended that these measures be considered exploratory and should not be used to penalize any certified health IT product or developer.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We acknowledge that some IIS are not able to return data for a query response and as such, agree that the finalized measure should be seen as informative and reflects the role that the health IT developers, health care 
                        <PRTPAGE P="1338"/>
                        providers, and IIS systems play with the exchange of this information. We acknowledge that an IIS may have issues in returning the data for response to the query, thus impacting the value of this measure. We recognize this contextual information will be important to note with the publication of these data. Where health IT developers encounter instances where a complete bidirectional loop is not possible, we encourage health IT developers to document this information in the supplemental reporting to allow for more complete understanding of the metrics.
                    </P>
                    <P>In this finalized measure, counts of queries sent to an IIS and responses received successfully are intended to provide insight on the functioning of bidirectional query to obtain immunization data. The metrics reported by health IT developers will provide new insights for ONC and the public health community that are currently unavailable at a national level. By understanding trends related to queries made and responses received over time, we will also gain feedback on the performance of queries and responses, which are part of the “transmission to immunization registries” (§ 170.315(f)(1)) criterion. As noted above, we will receive counts of the number of unique patients with an encounter during the reporting period, as proposed (and finalized) in the “consolidated clinical document architecture (C-CDA) problems, medications, and allergies reconciliation and incorporation through certified health IT” measure, and expect to use this data to provide encounter context to the “public health information exchange” measures. Together, these metrics can inform efforts to increase the availability of IIS data for health care providers to have a more complete immunization background for individuals and groups of patients. We plan to collaborate with the community to consider the measure of unique patients for whom queries were made to the IIS for future rulemaking.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested clarification on the proposed numerator. One commenter noted that the proposed numerator reflects the interoperability of the IIS, not the certified health IT, and requested clarification on “received,” stating that the successful response definition is not clear in cases where the error can be detected by the certified health IT in the IIS response such as “received technically” versus “received into the chart.” A few commenters requested clarification on how “refines” are counted for measurement, when a query attempt must be refined before a successful attempt, and suggested the numerator should reflect total queries performed.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the concern expressed that the metric does not reflect the interoperability of certified health IT. Through our measures we seek to assess bidirectional exchange activity between IIS and certified health IT, which can help identify potential issues related to interoperability and track trends over time. We appreciate the comments and the opportunity to provider greater clarity. In this final rule, we clarify that the metrics for the number of query responses received successfully from IISs overall, and by IIS, should count an IIS response as “received technically,” in the form of a message or transaction. This clarification addresses that health care providers may not ingest all responses into the record. We agree that the initial query and each refined query should individually increment the total number of immunization queries sent to an IIS in order to acknowledge the effort to ensure a successful query.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A couple commenters expressed support that acknowledgement with a severity level of “E” be considered a failure for purposes of the measure. One commenter noted that an error with a severity level of “E” could be included in either an acknowledgment or a response (RSP) message. A couple commenters noted that a significant portion of messaging failures are communication failures where there will be no response received which should be excluded from the denominator or included in a separate metric. The commenter suggested that messages of “no patient found” or “too many patients” found, as well as messages with no response from the IIS (in the case of downtime, for example), would be considered successful. One commenter requested clarification on whether a query response message responding that a patient match was not possible should be counted in the numerator. The commenter also suggested that the submission of descriptive context should be required, stating that it may help with future evolution and fine tuning of the measures.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments received regarding that the measure should consider acknowledgements with a severity level of “E” as a failed message. We confirm that only severity level of “E” for messages are excluded from the metrics, the number of query responses received successfully from IISs overall and by IIS. We also appreciate the additional description of communication failure scenarios due to IIS downtime or other accessibility issues. We will collaborate with the community to monitor how these instances impact the measure's interpretation and determine if it should be revised in the future. At this time, we will not require health IT developers to provide separate counts for communication failures and counts of the descriptive context levels. We encourage health IT developers to capture information about communication failures as their functionality permits and include this explanation in the supplemental documentation.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         In our request for public comment regarding whether both Z42 and Z32 messages should be included in the metrics, several commenters suggested that both Z42 and Z32 messages be included, stating that both are objectively relevant to patient care, contain significantly similar content, and have both been implemented in the real world.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Given the support expressed in response to our specific question, the metrics, the number of query responses received successfully from IISs overall and by IIS will include Z42 and Z32 messages.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters representing health IT developers expressed concern related to the proposed measure's stratification by IIS and age. These commenters suggested that the initial implementation of the measure should only require administration submission counts and that the development burden was high relative to the value of the stratifications. Other commenters supported the stratifications as defined, given that not all jurisdictions require comprehensive adult reporting. One commenter noted that additional age stratification was unnecessary and might add complexity. One commenter suggested delaying or eliminating the “immunization history and forecasts” measure.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments that indicated support for the measure's proposed stratifications, but that development burden would be high especially associated with the age stratification. We acknowledge that the age stratification is not as critical early on for this measure (compared to the submission of immunization data) as there are no state and jurisdiction level mandates for querying history and forecasts which vary by age. Therefore, we have delayed the implementation of this measure from “year 1” to “year 2” to provide health IT developers more time to produce the measure. 
                        <PRTPAGE P="1339"/>
                        Furthermore, the reporting by IIS will be delayed to “year 3.” We have not removed this measure as suggested by one commenter as there was a high level of support for this measure and we are providing additional time to implement the metric and related stratification.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested clarification on how a query sent to multiple IIS should be counted. One commenter requested clarification on whether the first denominator should include only query response messages that support both the history and forecast. One commenter requested clarification on whether developers would be required to calculate a percentage and if so, ONC must provide explicit guidance on the calculation components.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We clarify that the metrics related to the total number of immunization queries sent (overall and by IIS), should be incremented for each query sent to an IIS and the metrics related to number of query responses received successfully from an IIS (overall and by IIS), should increment for each successful message received. The measure should count queries and response messages so that the increment occurs for history, forecast, or history and forecast. This approach is supported by the “transmission to immunization registries” (§ 170.315(f)(1)) criterion that treats forecast and history separately. At this time, health IT developers are not required to report separate metrics for forecast and history. We clarify that ONC will calculate percentages based on the counts that the health IT developer submits.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that they did not agree with excluding queries performed by health care providers who do not administer immunizations, while another commenter recommended excluding these health care providers for simplicity.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We acknowledge that the suggestion to constrain the measure to only include health care providers who immunize simplifies the interpretation of results. However, the National Vaccine Advisory Committee (NVAC) recommends that all healthcare professionals, regardless of whether they administer vaccines, routinely assess patients for vaccines due.
                        <SU>210</SU>
                        <FTREF/>
                         Furthermore, there was no consensus across the comments to make this change. In this phase of reporting, it may add burden for health IT developers to segment the measure by whether the health care providers are immunizing providers. Therefore, the measure does not make distinctions for health care providers who do and do not administer immunizations and will collaborate with the community to understand the potential to incorporate this aspect in future rulemaking.
                    </P>
                    <FTNT>
                        <P>
                            <SU>210</SU>
                             NVAC Standards for Adult Immunization Practice: 
                            <E T="03">https://www.cdc.gov/vaccines/hcp/adults/for-practice/standards/index.html.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Finalization of Measure</HD>
                    <P>We have finalized the measure as “immunization history and forecasts through certified health IT” in § 170.407(a)(3)(vii). We have revised the proposed measure based on public comments received. Specific metrics to support this finalized measure are listed below and described in the accompanying measure specification located on ONC's website. We also note that if regulatory baselines associated with the metrics change in the future—such as a revision to a criterion through notice and comment rulemaking—the measure specification would also be changed to ensure alignment with the revised criterion:</P>
                    <P>1. Number of immunization queries sent to IISs overall (year 2).</P>
                    <P>2. Number of immunization queries sent to IISs overall by IIS (year 3).</P>
                    <P>3. Number of query responses received successfully from IISs overall (year 2).</P>
                    <P>4. Number of query responses received successfully from IISs overall by IIS (year 3).</P>
                    <P>The reporting period for the measure and related metrics above consists of one calendar year. Data collection for these measures and associated metrics will begin during the second and third phase of reporting (which is described later in the preamble).</P>
                    <HD SOURCE="HD3">Encounters</HD>
                    <P>
                        For measures where patient encounters are relevant, we proposed the definition of an encounter should be based on the National Committee for Quality Assurance (NCQA) outpatient value set and SNOMED CT inpatient encounter codes. For outpatient codes, developers should use NCQA's Outpatient Value Set.
                        <E T="51">211 212</E>
                        <FTREF/>
                         For inpatient codes, developers should use SNOMED CT codes 4525004, 183452005, 32485007, 8715000, and 448951000124107.
                        <SU>213</SU>
                        <FTREF/>
                         Listed below is a description of each SNOMED CT code:
                    </P>
                    <FTNT>
                        <P>
                            <SU>211</SU>
                             See: 2022 Quality Rating System Measure Technical Specifications. Published October 2021. 
                            <E T="03">https://www.cms.gov/files/document/2022-qrs-measure-technical-specifications.pdf.</E>
                        </P>
                        <P>
                            <SU>212</SU>
                             NCQA's Outpatient Value Set is available with a user ID and login at 
                            <E T="03">https://store.ncqa.org/my-2021-quality-rating-system-qrs-hedis-value-set-directory.html;</E>
                             or 
                            <E T="03">https://vsac.nlm.nih.gov/valueset/expansions?pr=all</E>
                             OID: 2.16.840.1.113883.3.464.1003.101.12.1087.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>213</SU>
                             Available for search at 
                            <E T="03">https://www.findacode.com/index.html.</E>
                        </P>
                    </FTNT>
                    <FP SOURCE="FP-1">• Emergency department patient visit (procedure)—4525004</FP>
                    <FP SOURCE="FP-1">• Emergency hospital admission (procedure)—183452005</FP>
                    <FP SOURCE="FP-1">• Hospital admission (procedure)—32485007</FP>
                    <FP SOURCE="FP-1">• Hospital admission, elective (procedure)—8715000</FP>
                    <FP SOURCE="FP-1">• Admission to observation unit (procedure)—448951000124107</FP>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested guidance for implementation of encounter value sets. Commenters representing health IT developers suggested adopting a broad definition of encounters for developers to apply and map to their own classification structures, while others suggested constraining the codes to a more limited and defined set. One commenter suggested limiting inpatient encounter codes to discharges only.
                    </P>
                    <P>
                        Several commenters supported the proposed approach (FR 23832) to align Insights Condition value sets for encounters with CMS programs. Commenters representing quality measure developers supported the proposed value sets that are used in electronic clinical quality measures (eCQMs). While calling for alignment with CMS programs, several commenters representing health IT developers recommended that the encounter value sets should follow industry standards, such as the FHIR Encounter.type field in the US Core Implementation Guide.
                        <SU>214</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>214</SU>
                             
                            <E T="03">https://build.fhir.org/ig/HL7/US-Core/index.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Response.</E>
                         We agree with commenters on the importance of aligning encounter value sets with industry approaches as well as re-using existing value sets that support CMS programs to reduce the burden of developing and reporting Insights Condition measures. In the HTI-1 Proposed Rule (88 FR 23832), we proposed to define encounters leveraging a code set defined by the National Committee for Quality Assurance and recommended by the HITAC, while requesting comment on alternative approaches. We proposed this approach in large part to align with existing measurement approaches used within CMS programs. As commenters described, not all codes included in the proposed approach are reflected in the US Core IG version 6.1.0, which is the version we believe commenters referenced. Based on public comment, we have revised the definition of encounters to maintain alignment with 
                        <PRTPAGE P="1340"/>
                        definitions of encounters within existing quality measurement approaches used by CMS while responding to industry concerns about burden and potential misalignment. Specifically, several CMS programs, including the Promoting Interoperability Program and the Quality Payment Program, require the counting of encounters using specific codes, and CMS maintains an CQM library that specifies specific encounter codes related to quality measurement.
                        <SU>215</SU>
                        <FTREF/>
                         Developers of certified health IT have years of experience with those reporting efforts. Specifically, health IT certified to any criterion in § 170.315(c)(1) through (4) supports recording, importing, reporting or filtering CQMs, and health IT certified to § 170.315(g)(1) or (2), supports numerator recording and measure calculation for each Promoting Interoperability Program percentage-based measure. For the purpose of the Insights Condition, we define applicable encounters as all encounters that the developer includes in its calculation of encounters within the existing certification criteria in § 170.315(g)(1) or (2) and the CQMs that they have presented for certification as part of certification to § 170.315(c). For those developers that do not attest to any of the certification criteria at § 170.315(c), (g)(1) or (2), we specify that they include all encounters regardless of encounter code. Based upon analysis of the Certified Health IT Product List (CHPL), we note that of the 306 products currently certified to § 170.315(b)(2), 281 are certified to at least one of the included criteria, with 232 certified to criterion in § 170.315(c) and 260 certified to § 170.315(g)(1) or (g)(2).
                    </P>
                    <FTNT>
                        <P>
                            <SU>215</SU>
                             Medicare Promoting Interoperability Program Specification Sheets 
                            <E T="03">https://www.cms.gov/medicare/regulations-guidance/promoting-interoperability-programs/resource-library.</E>
                        </P>
                        <P>
                            eCQM Library 
                            <E T="03">https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/eCQM_Library.</E>
                        </P>
                    </FTNT>
                    <P>
                        In finalizing this approach, we have eliminated the prescriptive approach to defining value sets that delineate encounters taken in the HTI-1 Proposed Rule, which was based on a specific set of quality measures and their associated Value Sets. The finalized approach instead relies on existing developer competencies and experience as demonstrated by their existing certification to any criterion in § 170.315(c)(1) through (4), (g)(1) or (g)(2) while retaining a close link to existing quality measurement. Our goal in finalizing this approach is to build upon existing CMS program requirements, certification criteria, and developer of certified health IT's experience with these requirements. Rather than specify specific value sets, our intent is to allow the definition of an encounter to evolve as use of CQMs and approaches within this Program and the Quality Payment Program change. In finalizing this approach, we have also emphasized alignment with measurement within CMS programs (
                        <E T="03">i.e.,</E>
                         eCQM and Promoting Interoperability percentage-based measures) rather than following industry standards, such as the FHIR Encounter.type field in the US Core Implementation Guide. As approaches within CMS' programs come into alignment with industry standards, the measure of encounters within the Insights Condition will also come into alignment. For developers that do not currently support the identification of specific types of encounters, our intent is to avoid creating a new requirement to implement specific terminologies or code sets.
                    </P>
                    <HD SOURCE="HD3">Counts of Unique Patients</HD>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter opposed the use of unique patient counts in the proposed measures under the Insights Condition. Further, the commenter stated unique patient counts when aggregating across many certified health IT instances would require significant burden and cost to deduplicate across customer databases. The commenter requested that ONC either change to transaction-based counts or clarify that unique patient counts will be unique only within each instance of the certified health IT and can be duplicated across instances.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for this input, and as noted in the individuals' access to EHI measurement area section in this preamble, we have revised our definition of unique patient counts so that counts would only be unique within each instance of the certified health IT. We recognize the potential difficulty of de-duplicating unique patients across more than one instance of a certified health IT and clarify that the patient counts should be unique within the instance and can be duplicative across instances.
                    </P>
                    <HD SOURCE="HD3">3. Insights Condition and Maintenance of Certification—Requirements</HD>
                    <P>As stated in the HTI-1 Proposed Rule (88 FR 23843), the Cures Act specifies that a health IT developer be required, as a Condition and Maintenance of Certification requirement under the Program, to submit responses to reporting criteria in accordance with the “Electronic Health Record Reporting Program” established under section 3009A of the PHSA, as added by the Cures Act, with respect to all certified technology offered by such developer. We proposed to implement the Cures Act “Electronic Health Reporting Program” Condition and Maintenance of Certification requirements as the “Insights Condition and Maintenance of Certification” (Insights Condition) requirements in § 170.407. As a Condition of Certification, we proposed that developers of certified health IT would submit responses to comply with the Insights Condition's requirements, described in this section of the preamble in relation to the Insights Condition's measures and associated certification criteria.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of health IT developers expressed concern about the burden that collecting and reporting measures for the Insights Condition will impose on health IT developers. A commenter stated that developing Insights Condition measures overlaps and competes with health IT developers' other priorities, including CMS' digital quality initiative and user requested analytics. One commenter expressed concern that the requirements would introduce barriers to market entry and reduce competition. However, one health IT developer commented that they do not believe that the Insights Condition presents a significant regulatory burden, as the measure data can be collected and reported using currently widespread technologies.
                    </P>
                    <P>
                        Relatedly, many commenters, including health IT developers, developer associations, and health systems, opposed the overall number and type of measures proposed in § 170.407 for the Insights Condition. Commenters suggested reducing the number and complexity of measures to reduce burden and improve feasibility for developers of certified health IT and their customers. Commenters stated the number of measures is higher than described due to the multiple numerators and denominators. Commenters recommended ONC remove the list of expected metrics or ratios and focus only on the individual data elements to be collected and reported. Some commenters suggested 10 or fewer counts as a starting point. One commenter indicated that there were duplicate measures in the set that should be combined or harmonized. One commenter recommended that ONC select measures that are well-defined and targeted, and designed not to heavily burden health IT system resources when collecting data. Commenters also suggested gradually increasing the number of measures over several years.
                        <PRTPAGE P="1341"/>
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the concerns expressed for the potential burden imposed on health IT developers to report the Insight Condition measures. We emphasize the Insights Condition fulfills the Cures Act specified requirements in section 4002(c) to establish an Electronic Health Record (EHR) Reporting Program to provide transparent reporting on certified health IT.
                    </P>
                    <P>We believe this final rule will address information gaps in the health IT marketplace and provide useful insights on certified health IT use while minimizing implementation burden on health IT developers. Our final rule includes multiple revisions to our proposals, described in greater detail throughout this section of the preamble under their respective sections, that are intended to minimize the burden on health IT developers in implementing the Insights Condition. In sum, for this final rule, we have:</P>
                    <P>• Delayed the submission of the first phase of measures and related metrics to July 2027 to allow health IT developers adequate time to develop and implement the measures.</P>
                    <P>• Established a more incremental approach for implementing the measures over a longer timeframe (three years), including phasing in more complex aspects of the measures. Extending the time frame will allow developers to work on other priorities, such as CMS' digital quality initiative and user requested analytics, and not have to exclusively focus on developing Insights Condition measures.</P>
                    <P>• Not finalized two proposed measures (“electronic health information export through certified health IT” and “C-CDA documents obtained using certified health IT by exchange mechanism”).</P>
                    <P>• Addressed potentially duplicate metrics to make it easier to understand the total number of unique metrics that are required. For example, the same encounter-related metrics were previously listed in the patient access, immunization, and clinical exchange measure specification. Those metrics are now only listed in the clinical exchange section and measure specification.</P>
                    <P>• Reduced the frequency of measure reporting from semiannual to annual, and changed the submission date for more convenience to health IT developers.</P>
                    <P>• Provided an alternative reporting approach for health IT developers who are not able to report on their entire customer base due to contractual reasons. This should limit the need to renegotiate contracts for the sole reason of complying with the Insights Condition requirements addressing a major source of burden. This approach is described below in section III.F.4 of this final rule.</P>
                    <P>• Supported health IT developers who choose to use their Insights Condition measurements and data as part of their Real World Testing plans and results, thus reducing the need to generate separate data for both Conditions of Certification.</P>
                    <P>• Replaced the terms numerators and denominators, which caused confusion from commenters, with lists of metrics within each measure that health IT developers will be required to report, and limited stratification of measures.</P>
                    <P>• Consolidated the required Insights Condition measures and related metrics into the table that is located later in this section of the preamble.</P>
                    <P>We do not believe that the Insights Condition introduces a barrier to market entry. The minimum reporting qualifications we proposed and have subsequently finalized further below in this preamble are designed to ensure that small and startup developers are not unduly disadvantaged by the Insights Condition requirements. Further, the availability of information on what capabilities are widely available or lacking in the marketplace may encourage new entrants to provide needed technologies.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters raised concerns that customers of health IT developers will perceive burden and lack incentives that would impact their willingness to allow access to data for health IT developers to report in order to comply with the Insights Condition requirements. A few commenters encouraged ONC to coordinate with CMS on ways to provide insights on EHI access, exchange, and use while reducing physician burden related to requirements for the Insights Condition and the CMS Promoting Interoperability Programs.
                    </P>
                    <P>Several commenters suggested ONC collaborate with CMS to adopt regulatory requirements to promote customers of health IT developers to agree to allow data from their systems to be used for the Insights Condition. One medical professional society commenter suggested that ONC coordinate with CMS and use the Insights Condition data and metrics to augment CMS physician reporting requirements. Further, the commenter stated the goals of reducing physician reporting burden and providing CMS and ONC insight into EHI access, exchange, or use can be jointly achieved by allowing physicians to attest to meeting CMS reporting requirements, rather than reporting a numerator-denominator, supplemented by health IT developers reported data under the Insights Condition. One commenter stated that attestations exist for agreeing to cooperate with ONC-ACB surveillance activities as a precedent for such an attestation requirement.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the suggestion for ONC to collaborate with CMS. We recognize that health care providers in certain CMS programs were expected to attest to cooperate in “good faith” with both ONC-ACB surveillance activities and ONC Direct Reviews.
                        <E T="51">216 217</E>
                        <FTREF/>
                         We will explore potential opportunities with CMS to encourage support for the Insights Condition among hospitals, physicians and other healthcare professionals that participate in CMS programs. We will also explore potential opportunities with CMS on ways to reduce burden on physicians and other health care providers related to reporting requirements. We will continue to coordinate and work with CMS on points of intersection for potential future rulemaking.
                    </P>
                    <FTNT>
                        <P>
                            <SU>216</SU>
                             42 CFR 495.40(a)(2)(i)(H). Demonstration of meaningful use criteria. 
                            <E T="03">https://www.ecfr.gov/current/title-42/chapter-IV/subchapter-G/part-495#p-495.40(a)(2)(i)(H).</E>
                        </P>
                        <P>
                            <SU>217</SU>
                             42 CFR 414.1375(b)(3). Promoting Interoperability (PI) performance category. 
                            <E T="03">https://www.ecfr.gov/current/title-42/chapter-IV/subchapter-B/part-414/subpart-O/section-414.1375.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concern that the Insights Condition reporting requirements will lead to increased burden or frustration for health care providers and health care provider organizations and encouraged ONC to consider the impacts of Insights Condition reporting by health IT developers on their customers. Commenters also expressed concerns that health IT developers will `pass on' the burden of reporting to end users (
                        <E T="03">i.e.,</E>
                         health care providers), who will end up being required to assist their developers of certified health IT in collecting data or creating reports for the Insights Condition. Some commenters indicated that health care providers and health care provider organizations are already overburdened with reporting requirements. One commenter expressed concern about creating any additional direct or indirect reporting burden for rural and underserved health care providers. A few commenters suggested to reduce health care provider burden by making healthcare organization participation and data contribution optional and avoid selecting measures that will require mapping of data by the healthcare organization staff. One advocacy organization and a health system expressed support for ONC efforts to 
                        <PRTPAGE P="1342"/>
                        establish the Insights Condition and encouraged ONC to minimize its administrative burdens.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the concerns expressed by commenters and aims to minimize burden on customers of developers of certified health IT related to the Insights Condition. We emphasize that developers of certified health IT are responsible for reporting the Insights Condition measures, and that health care providers, including health care providers who provide care to rural and underserved populations, are not responsible for reporting under the Insights Condition.
                    </P>
                    <P>We have sought to design the measures so they would not require providers to separately collect data outside of their normal activities as part of delivering care or create reports to assist developers of certified health IT for the Insights Condition measures. The measures are designed to come from system-generated data and not involve additional effort by health care providers. We believe that, using widely available database technology, health IT developers should be able to collect data required for reporting under the Insights Condition without significant end-user burden. As noted in the clinical care information exchange measurement area of the preamble, we did not adopt the “C-CDA documents obtained using certified health IT by exchange mechanism” measure, partly because it was identified as potentially requiring mapping of data at the healthcare organization level.</P>
                    <P>
                        We describe earlier in this section of the preamble the multiple changes to our proposals that are intended to minimize the burden on health IT developers in implementing the Insights Condition. These changes to our proposals are also intended to minimize the burden on customers of health IT developers. We believe this final rule includes several changes to our proposals that significantly reduce potential indirect burden on users (
                        <E T="03">i.e.,</E>
                         health care providers) of certified health IT. As noted earlier, we provide health IT developers with an alternative reporting option if they are unable to report on all their customers due to contractual reasons.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One health system expressed support for the Insights Condition and requested clarification on how health IT developers will have access to the information in locally installed systems to complete the reporting while maintaining appropriate confidentiality.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this comment. We expect that confidentiality would already be addressed in existing contracts or business agreements between the health IT developer and their customers. Health IT developers will not submit protected health information or personally identifiable information to ONC under the Insights Condition. The data that we are requiring health IT developer to report is aggregated at the product level and is not at the health care provider or patient level.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters were supportive of the measures in general, but recommended restructuring the measures as a single set, in table format identifying the associated certification criteria, with numerator/denominator pair as its own row. Some commenters provided a sample format for our consideration.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We have taken a more streamlined approach to categorizing, describing, and displaying the measures under the Insights Condition. We also refer readers to the HTI-1 Proposed Rule (88 FR 23831) for detailed background and history of the proposed measures as each measure description includes statements on the intent of the measure. For example, in the HTI-1 Proposed Rule (88 FR 23834), we specified under the “individuals' access to electronic health information supported by certified API technology” (now finalized as the “individuals' access to electronic health information through certified health IT”) measure that we believe this measure would provide a national view into how individuals access their EHI and would inform ONC and health IT community efforts to empower individuals with access to their EHI.
                    </P>
                    <P>We provide the table below to define the updated metrics that health IT developers are required to provide to ONC at the product level. The table identifies the metrics a health IT developer is required to report based on the certification criterion to which the health IT developer certifies. We reiterate that the health IT developer is responsible for providing and aggregating the data for each applicable “metric” at the product level. The table reflects the metrics that have been modified in some cases based on public comment and described in more detail below. We clarify that “year 1” refers to the first implementation year of the Insights Condition. Data collection during “year 1” starts in calendar year 2026 (January 1st, 2026-December 31st, 2026), with responses due in July 2027. Reporting is on an annual basis thereafter. The measures designated with “year 2” will begin data collection calendar year 2027, with responses due in July 2028 (and annually thereafter). The “year 3” measures start data collection in calendar year 2028, with responses due July 2029 (and annually thereafter). The reporting period for each of the measures below consists of one calendar year. Please refer to the measure specifications for details on the metrics, including definitions.</P>
                    <GPOTABLE COLS="4" OPTS="L2,nj,i1" CDEF="s100,xs72,r150,r25">
                        <TTITLE>Table 2—List of Insights Condition Measure Metrics</TTITLE>
                        <BOXHD>
                            <CHED H="1">Measure title</CHED>
                            <CHED H="1">Associated certification criteria</CHED>
                            <CHED H="1">Metrics</CHED>
                            <CHED H="1">Program year</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Individuals' Access to Electronic Health Information Through Certified Health IT</ENT>
                            <ENT>§ 170.315(g)(10)</ENT>
                            <ENT>1. Number of unique individuals who accessed their EHI using technology certified to “standardized API for patient population services” certification criterion under § 170.315(g)(10)</ENT>
                            <ENT>Year 1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>§ 170.315(e)(1)</ENT>
                            <ENT>2. Number of unique individuals who accessed their EHI using technology certified to the “view, download, and transmit to 3rd party” certification criterion under § 170.315(e)(1)</ENT>
                            <ENT>Year 1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>
                                § 170.315(g)(10) or
                                <LI>§ 170.315(e)(1)</LI>
                            </ENT>
                            <ENT>3. Number of unique individuals who accessed their EHI using any method.</ENT>
                            <ENT>Year 1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Consolidated Clinical Document Architecture (C-CDA) Problems, Medications, and Allergies Reconciliation and Incorporation Through Certified Health IT</ENT>
                            <ENT>§ 170.315(b)(2)</ENT>
                            <ENT>4. Number of encounters</ENT>
                            <ENT>Year 2.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>5. Number of unique patients with an encounter</ENT>
                            <ENT>Year 2.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>6. Number of unique patients with an associated C-CDA document</ENT>
                            <ENT>Year 2.</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="1343"/>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>7. Number of total C-CDA documents obtained</ENT>
                            <ENT>Year 2.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>8. Number of unique C-CDA documents obtained</ENT>
                            <ENT>Year 2.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>9. Number of total C-CDA documents obtained that were pre-processed</ENT>
                            <ENT>Year 2.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>10. Number of total C-CDA documents obtained that were not pre-processed</ENT>
                            <ENT>Year 2.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>11. Number of total C-CDA documents obtained that were pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method</ENT>
                            <ENT>Year 3.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>12. Number of total C-CDA documents obtained that were not pre-processed where problems, medications, or allergies and intolerances were reconciled and incorporated via any method</ENT>
                            <ENT>Year 3.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>13. Number of total C-CDA documents obtained that were determined to have no new problems, medications, or allergies and intolerances information by pre-processes or fully automated processes</ENT>
                            <ENT>Year 3.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Applications Supported Through Certified Health IT</ENT>
                            <ENT>§ 170.315(g)(10)</ENT>
                            <ENT>14. Application name(s)</ENT>
                            <ENT>Year 1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>15. Application developer name(s)</ENT>
                            <ENT>Year 1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>16. Intended purpose(s) of application</ENT>
                            <ENT>Year 1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>17. Intended application user(s)</ENT>
                            <ENT>Year 1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>18. Application status</ENT>
                            <ENT>Year 1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Use of FHIR in Apps Through Certified Health IT</ENT>
                            <ENT>§ 170.315(g)(10)</ENT>
                            <ENT>19. Number of distinct certified health IT deployments (across clients) active at any time during the reporting period, overall and by user type</ENT>
                            <ENT>Year 1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>20. Number of requests made to distinct certified health IT deployments that returned at least one FHIR resource by FHIR resource type</ENT>
                            <ENT>Year 1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>21. Number of distinct certified health IT deployments (across clients) associated with at least one FHIR resource returned overall and by user type</ENT>
                            <ENT>Year 1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT O="xl"/>
                            <ENT>22. Number of distinct certified health IT deployments (across clients) associated with at least one FHIR resource returned by US Core Implementation Guide version</ENT>
                            <ENT>Year 2.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Use of FHIR Bulk Data Access Through Certified Health IT</ENT>
                            <ENT>§ 170.315(g)(10)</ENT>
                            <ENT>23. Number of distinct certified health IT deployments (across clients) that completed at least one bulk data access request</ENT>
                            <ENT>Year 2.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>§ 170.315(g)(10)</ENT>
                            <ENT>24. Number of bulk data access requests completed (across clients) to export all data requested for patients within a specified group</ENT>
                            <ENT>Year 2.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Immunization Administrations Electronically Submitted to Immunization Information Systems Through Certified Health IT</ENT>
                            <ENT>§ 170.315(f)(1)</ENT>
                            <ENT>25. Number of immunizations administered overall</ENT>
                            <ENT>
                                Year 1
                                <LI>(overall).</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>§ 170.315(f)(1)</ENT>
                            <ENT>26. Number of immunizations administered overall, by IIS and by age category</ENT>
                            <ENT>
                                Year 2
                                <LI>(by IIS and age category).</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>§ 170.315(f)(1)</ENT>
                            <ENT>27. Number of immunizations administered electronically submitted successfully to IISs overall</ENT>
                            <ENT>
                                Year 1
                                <LI>(overall).</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>§ 170.315(f)(1)</ENT>
                            <ENT>28. Number of immunizations administered electronically submitted successfully to IISs overall, by IIS and by age category</ENT>
                            <ENT>
                                Year 2
                                <LI>(by IIS and age category).</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Immunization History and Forecasts Through Certified Health IT</ENT>
                            <ENT>§ 170.315(f)(1)</ENT>
                            <ENT>29. Number of immunization queries sent to IISs overall</ENT>
                            <ENT>
                                Year 2
                                <LI>(overall).</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>§ 170.315(f)(1)</ENT>
                            <ENT>30. Number of immunization queries sent to IISs overall by IIS</ENT>
                            <ENT>
                                Year 3
                                <LI>(by IIS).</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>§ 170.315(f)(1)</ENT>
                            <ENT>31. Number of query responses received successfully from IISs overall</ENT>
                            <ENT>
                                Year 2
                                <LI>(overall).</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>§ 170.315(f)(1)</ENT>
                            <ENT>32. Number of query responses received successfully from IISs overall by IIS</ENT>
                            <ENT>
                                Year 3
                                <LI>(by IIS).</LI>
                            </ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter noted that ONC only proposed Insights Condition measures for the interoperability category. The commenter further noted that the Cures Act included other categories, including usability and user-centered design, security, conformance to certification testing, and other categories, as appropriate to measure the performance of EHR technology. The commenter encouraged ONC to focus on these 
                        <PRTPAGE P="1344"/>
                        additional areas for future measure development for the Insights Condition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for their encouragement to consider other areas for future measure development. As described in our HTI-1 Proposed Rule (88 FR 23832), we intend for this first set of measures to provide insights on the interoperability category specified in the Cures Act. We intend to explore the other Cures Act categories (security, usability and user-centered design, conformance to certification testing, and other categories to measure the performance of EHR technology) in future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that Conditions and Maintenance of Certification requirements including the Insights Condition should actively seek to identify bias and prevent use of algorithms that may cause discrimination against patients.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this suggestion and will consider ways that the Conditions and Maintenance of Certification requirements can help reduce bias and prevent harmful use of algorithms in patient care. We note that this final rule includes requirements that aim to introduce information transparency about Predictive DSIs supplied by health IT developers as part of their certified Health IT Modules, so that potential users have sufficient information about how a Predictive DSI was designed, developed, trained, and evaluated to determine whether it is trustworthy, including evaluation of fairness or bias. We refer readers to section III.C.5 (Decision Support Interventions and Predictive Models) of this final rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter questioned whether ONC could get the information about some Insights Condition measures from existing sources.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this comment. As described in our HTI-1 Proposed Rule (88 FR 23831), our approach for identifying measures for the Insights Condition included several considerations, including measures reflecting information that ONC cannot obtain without regulation and efforts that are not duplicative of other data collection. We will continue to consider ways to reuse other data and reduce reporting burden while addressing information gaps in the health IT marketplace through the Insights Condition. Thus, the measures we finalized address an important gap in information that can help assess interoperability.
                    </P>
                    <HD SOURCE="HD3">Cross-Cutting Requirements</HD>
                    <P>In the HTI-1 Proposed Rule (88 FR 23832), we also proposed to apply certain requirements across multiple measures, including, but not limited to: (1) data submitted by health IT developers would be provided and aggregated at the product level (across versions); (2) health IT developers would provide documentation related to the data sources and methodology used to generate these measures; and (3) health IT developers may also submit descriptive or qualitative information to provide context as applicable.</P>
                    <P>
                        We explained in the HTI-1 Proposed Rule (88 FR 23832) that overall, the documentation should help ensure the responses/data are interpreted correctly. Thus, the documentation related to the data sources and methodology would include the types of data sources used, how the measure was operationalized (
                        <E T="03">e.g.,</E>
                         any specific definitions), any assumptions about the data collected, information on the providers or products that are included/excluded from the reported data, and a description about how the data was collected. As described earlier in the preamble, we would then use the measure data submitted by health IT developers to calculate the metrics (
                        <E T="03">e.g.,</E>
                         percentages and other related statistics). Developers of certified health IT would submit this information to an independent entity, per statutory requirements in section 3009A(c) of the PHSA, as part of the implementation of the Insights Condition, which we discuss later in this section of the preamble.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters supported our proposal under the Insights Condition to require developers of certified health IT to report documentation used to generate each measure. Three commenters also supported the proposal for reporting optional documentation. One commenter favored requiring health IT developers to explicitly outline how they collect, aggregate, and analyze the data for the Insights Condition, including documentation on the assumptions made about the data and decisions made about the inclusion or exclusion of specific data and/or installations. Some commenters suggested that ONC establish consistent topics and categories for the required documentation submissions and requested having the option to keep the additional information submissions confidential. One commenter recommended that ONC prohibit developers from using trade secrets to prevent validation of reporting data. One commenter requested ONC define a clear and accessible pathway for public access to the Insights Condition data, as well as how identified issues will be mitigated by developers certified health IT. Further, the commenter noted that methodological transparency is essential to inform customers, regulators, and policymakers about what the Insights Condition was testing, how testing was performed, and what the reporting informs about achievement of interoperability objectives.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. We have finalized that developers of certified health IT are required under the Insights Condition to provide documentation related to the data sources and methodology used to generate these measures, and health IT developers may also submit descriptive or qualitative information to provide context as applicable. Later in this preamble, we also note that in accordance with the Cures Act, we intend to make responses (the metrics and required documentation) to the Insights Condition publicly available on our website. The metrics and required documentation will provide methodological transparency and enable assessing progress related to interoperability as requested by commenters.
                    </P>
                    <P>
                        We require that health IT developers, as part of their responses, will provide documentation used to generate the measures for more accurate and complete data calculation. As we stated in the HTI-1 Proposed Rule (88 FR 23832), the documentation should help ensure the data are interpreted correctly. Therefore, the documentation related to the data sources and methodology should include the types of data sources used, how the measure was operationalized (
                        <E T="03">e.g.,</E>
                         any specific definitions), any assumptions about the data collected, information on the health care providers or products that are included/excluded from the metrics, and a description about how the data was collected. We intend to make the required documentation provided by health IT developers publicly available for the purposes of transparency and to allow interested parties to understand and interpret the data.
                    </P>
                    <P>
                        We do not anticipate that health IT developers will need to share any information they consider proprietary, trade secret, or confidential information for the required documentation related to the Insights Condition. The documentation identified above does not specifically require the disclosure of proprietary, trade secret, or confidential information. Health IT developers should be able to report without the 
                        <PRTPAGE P="1345"/>
                        sharing of any such information. If health IT developers wish to provide additional information as part of the optional documentation, we strongly encourage them to not include any proprietary, trade secret, or confidential information in their submission. Further, we intend to provide a method for health IT developers to first indicate whether they plan to share proprietary, trade secret, and/or confidential information for purposes of either required or optional documentation. If a health IT developer provides an affirmative indication, ONC will engage the developer in dialogue about potential alternative means of meeting either required documentation requirements or providing optional documentation (
                        <E T="03">e.g.,</E>
                         in other generalized or descriptive ways that may achieve the same goal). As we noted in the Enhanced Oversight and Accountability (EOA) Final Rule (81 FR 72429), we will implement appropriate safeguards to ensure, to the extent permissible under federal law, that any proprietary business information or trade secrets that are disclosed by the health IT developer in its documentation would be kept confidential by ONC.
                        <SU>218</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>218</SU>
                             The Freedom of Information Act, 18 U.S.C. 1905, and the Uniform Trade Secrets Act, 18 U.S.C. Chapter 90, generally govern the disclosure and descriptions of these types of information.
                        </P>
                    </FTNT>
                    <P>
                        We also refer readers to section III.F.4 of this final rule where we describe how we intend for health IT developers to submit the metrics and related documentation electronically using a web-based form, which will provide templates that enable submitting the data to ONC in a structured, electronic format such as comma-separated values (CSV) or JavaScript Object Notation (JSON) for this purpose. For questions and comments that may arise in reviewing the results and supporting documentation, we encourage the public to follow the Certified Health IT Complaint Process described at: 
                        <E T="03">https://www.healthit.gov/topic/certified-health-it-complaint-process.</E>
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters opposed our proposal that developers of certified health IT report measures aggregated at the product level, across product versions. Several commenters recommended that ONC adopt a flexible approach where health IT developers can report either at the product or developer level with an attestation to indicate which level the health IT developer reported. Commenters noted that this level of flexibility is consistent with the Real World Testing Condition.
                    </P>
                    <P>Some commenters stated that health IT developers with integrated products or platforms are not able to differentiate certain Insights Condition measures per product as proposed, making product level reporting impossible. In this circumstance, one action would be counted under multiple products. One commenter recommended reporting be permitted at the integrated database level instead of the product level to make reporting feasible. One commenter recommended reporting at the developer level to avoid duplicate counting. One commenter stated health IT developers with both cloud and non-cloud-based products would have problems aggregating data for reporting. Several commenters opposed any reporting at a level lower than a certified Health IT Module.</P>
                    <P>Three commenters requested reporting that is more granular, at the product version level. Commenters stated product version level reporting would better support health care provider and healthcare organization evaluation and comparison of health IT capabilities.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback and acknowledge the variety of perspectives on this requirement. We have maintained and finalized in § 170.407(a)(1)(i)(A) that data submitted by health IT developers would need to be provided and aggregated at the product level (across versions). However, we recognize that integrated products, which serve multiple settings or support multiple CHPL ID products, will not be able to differentiate between the settings or CHPL IDs when reporting on the measures. This could result in either double-counting or only reporting for one product. To address this issue, we have revised our requirement, related to integrated products, so that integrated products will only have to report one response for two or more products that are integrated. The web-based form and templates will allow for health IT developers to identify as submitting on behalf of an integrated product and to provide the associated CHPL IDs with the response.
                    </P>
                    <P>
                        We believe that product level data would provide insights on how performance on the measures vary by market (
                        <E T="03">e.g.,</E>
                         inpatient, outpatients, specialty) and by capabilities of products, whereas this type of insight would not be available at the developer level. A product level focus is also aligned with other Program reporting requirements that allow for product level reporting, such as the Real World Testing Condition and Maintenance of Certification (85 FR 25765).
                    </P>
                    <P>In considering alternatives, such as proposing to require health IT developers to report measures at the health IT developer level or at the most granular level of product version/CHPL ID, we concluded that proposing to require data to be reported at the health IT developer level is unlikely to reduce burden given that data would still need to be obtained from each applicable product and then aggregated. We also concluded that proposing to require reporting at the product version/CHPL ID level could significantly increase burden because developers of certified health IT would need separate reports for each version of their products. A flexible approach with a mix of data at the developer and product levels does not allow for a consistent analysis and reporting across health IT developers.</P>
                    <HD SOURCE="HD3">Minimum Reporting Qualifications</HD>
                    <P>As required by section 3009A(a)(3)(C) of the PHSA, ONC worked with an independent entity, the Urban Institute, to develop measure concepts for the Insights Condition that would not unduly disadvantage small and startup developers. For detailed background, we refer readers to the HTI-1 Proposed Rule (88 FR 23843). Additionally, we proposed (88 FR 23844) to implement the Insights Condition requirements in a way that does not unduly disadvantage small and startup developers of certified health IT. We proposed (88 FR 23844) to establish minimum reporting qualifications that a developer of certified health IT must meet to report on the measure. Developers of certified health IT who do not meet the minimum reporting qualifications (as specified under each measure), would submit a response to specify that they do not meet the minimum reporting qualifications under the Insights Condition measure. In this way, all developers of certified health IT would report on all measures, even if some report that they do not meet the minimum reporting qualifications.</P>
                    <P>
                        In the HTI-1 Proposed Rule (88 FR 23844), we proposed that the minimum reporting qualifications include whether a health IT developer has any applicable Health IT Modules certified to criteria associated with the measure, and whether the developer has at least 50 hospital users or 500 clinician users across its certified health IT products, which serves as a proxy for its size or maturation status (
                        <E T="03">e.g.,</E>
                         whether it is a startup) and refer readers to the HTI-1 Proposed Rule for details on how we determined the proposed thresholds for health IT developers (88 FR 23845).
                    </P>
                    <P>
                        We proposed (88 FR 23844) that if a developer of certified health IT does not 
                        <PRTPAGE P="1346"/>
                        meet these minimum reporting qualifications, it would be required to submit a response that it does not meet the minimum reporting qualifications on specific measures for a given Health IT Module(s) subject to the Insights Condition requirements. In addition, we proposed (88 FR 23844) that if a health IT developer does not have at least one product that meets the applicable certification criteria specified in the measure requirements, or a developer of certified health IT that is certified to the criterion or criteria specified in the applicable measure during the reporting period but does not have any users using the functionality, the developer would still be required to submit a response that it does not meet the applicable certification criteria or the number of users required to report on the measure.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters supported our proposal to establish minimum reporting qualifications that a developer of certified health IT must meet to report on each measure. However, commenters stated that minimum reporting qualification would be more appropriate at the product level instead of at the developer level. Commenters recommended ONC maintain the proposed minimum reporting qualifications and apply those qualifications to individual products. One commenter recommended applying the thresholds at the product version level.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the interest expressed in applying the minimum reporting qualifications at the product or product version levels. However, we believe applying minimum reporting qualifications at the developer level adequately addresses the Cures Act requirement for the Insights Condition to not unduly disadvantage small and startup health IT developers. Applying minimum reporting qualifications at the product or product version levels could result in missing valuable data related to the use of certain certified health IT products.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters made a few requests for clarification on the minimum reporting qualifications. One commenter indicated that our minimum reporting qualifications are ambiguous and asked ONC to clarify if the minimum reporting qualification is “50 users in a hospital” or “50 hospital sites that have users.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. We have finalized the minimum reporting qualification in § 170.407(a)(2) to be at least 50 hospital sites or 500 individual clinician users across the developer's certified health IT. We note that the 50 hospital sites threshold is applicable to health IT modules used in inpatient or emergency department settings, while the 500 individual clinician users threshold is applicable to health IT modules used in outpatient/ambulatory settings (non-inpatient).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed that requiring health IT developers attest to not having technology certified to a given criterion for purposes of not reporting data for a specific Insights Condition measure was redundant since ONC maintains the list of certified health IT products.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The Cures Act requires that all developers of certified health IT report on all Insights Condition measures. We believe this attestation process provides for compliance with that requirement in the simplest way.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested that the definition of “developer” be more specific to include the actual architects and engineers of the software itself. The commenter questioned if the current definition of “developer” could also be interpreted to include organizations that provide certified health IT access for practices/clinicians under MSSP agreements. Further, the commenter noted these healthcare organizations would not have resources to comply with the Insights Condition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The Conditions and Maintenance of Certification requirements in subpart D of 45 CFR part 170 apply to developers participating in the Program (see 45 CFR 170.400). Therefore, the finalized “Insights Condition and Maintenance of Certification” requirements (codified in § 170.407) apply to developers participating in the Program that meet minimum reporting qualifications. Although we discuss the finalized “offer health IT” and updated “health IT developer of certified health IT” definitions for purposes of the information blocking regulations (45 CFR part 171), as discussed in sections IV.B.1 and IV.B.2 of this preamble, this commenter's request is out of scope for this final rule since we did not propose a definition in the HTI-1 Proposed Rule, and there is no codified definition of “developer” specific to the Program regulations in 45 CFR part 170 at this time.
                    </P>
                    <HD SOURCE="HD3">4. Insights Condition and Maintenance of Certification—Process for Reporting</HD>
                    <P>
                        We proposed (88 FR 23846) in § 170.407(b)(1) that, as a Maintenance of Certification requirement for the Insights Condition, developers of certified health IT would need to submit responses every six months (
                        <E T="03">i.e.,</E>
                         two times per year) for any applicable certified Health IT Module(s) that have or have had an active certification at any time under the Program during the prior six months. We also proposed to provide developers of certified health IT with ample time to collect, assemble, and submit their data. We proposed (88 FR 23846) that developers of certified health IT would be able to provide their submissions within a designated 30-day window, twice a year. Developers of certified health IT would begin collecting their data twelve months prior to the first 30-day submission window. The first six months of this period would be the period that developers of certified health IT would report on for the first 30-day submission window. Developers of certified health IT would then have the next six months to assemble this data for reporting. During the second six months of this period, developers of certified health IT would begin collecting data for the next 30-day submission window and so on. We refer readers to the example we provided in the HTI-1 Proposed Rule (88 FR 23846).
                    </P>
                    <P>We proposed (88 FR 23847) in § 170.407(b)(1)(i) that a developer of certified health IT must provide responses beginning April 2025 for the following measures: (1) individuals' access to electronic health information; (2) applications supported through certified health IT; (3) immunization administrations electronically submitted to an immunization information system through certified health IT; and (4) immunization history and forecasts. We proposed (88 FR 23847) in § 170.407(b)(1)(ii) that a developer of certified health IT must provide responses beginning April 2026 for the remaining measures: (1) C-CDA documents obtained using certified health IT by exchange mechanism; (2) C-CDA medications, allergies, and problems reconciliation and incorporation using certified health IT; (3) use of FHIR in apps supported by certified API technology; (4) use of FHIR bulk data access through certified health IT; and (5) electronic health information export through certified health IT. For further discussion regarding our rationale for these proposals, we refer readers to the HTI-1 Proposed Rule (88 FR 23847).</P>
                    <P>
                        We welcomed comments on our proposed approach, as well as the proposed frequency of reporting, other frequencies of reporting such as more or less frequent, and any additional burdens that should be considered for developers of certified health IT to meet the proposed “Insights Condition and Maintenance of Certification” requirements.
                        <PRTPAGE P="1347"/>
                    </P>
                    <P>We also noted in the HTI-1 Proposed Rule (88 FR 23847) that there may be other factors that could impact a developer of certified health IT's ability to easily collect data to comply with the Insights Condition's requirements. For example, a developer of certified health IT may have contracts or business agreements that inhibit the health IT developer's ability to collect data from its customers. We noted that in such scenarios, developers of certified health IT would need to renegotiate their contracts if we finalized our proposals. We explained that we expected developers of certified health IT would work to mitigate any issues and provisions affecting their ability to comply with this Condition and Maintenance of Certification requirement. Therefore, a developer of certified health IT that is required to meet the Insights Condition's requirements must submit responses or may be subject to ONC direct review of the Conditions and Maintenance of Certification requirements, corrective action, and enforcement procedures under the Program. We welcomed comments on our approach, as well as any specific hardships certified health IT may encounter with the Insights Condition of Certification.</P>
                    <P>We proposed (88 FR 23847) that responses to the Insights Condition would occur via web-based form and method, consistent with the requirements in § 3009A(c) of the PHSA. We noted that under the statute, developers of certified health IT must report to an “independent entit[y]” to “collect the information required to be reported in accordance with the criteria established.” We intend to award a grant, contract, or other agreement to an independent entity as part of the implementation of the Insights Condition and will provide additional details through subsequent information. We stated that we intend to make responses publicly available via an ONC website, and we intend to provide developers of certified health IT the opportunity to submit qualitative notes that would enable them to explain findings and provide additional context and feedback regarding their submissions.</P>
                    <P>Further, we proposed (88 FR 23847) a new Principle of Proper Conduct for ONC-Authorized Certification Bodies (ONC-ACBs) in § 170.523(u) that would require ONC-ACBs to confirm that applicable developers of certified health IT have submitted their responses for the Insights Condition of Certification requirements in accordance with our proposals. We stated an expectation that the ONC-ACBs would confirm whether or not the applicable health IT developers submitted responses for the Insights Condition of Certification requirements within the compliance schedule. The intent of this responsibility is not to duplicate the work of the independent entity in collecting and reviewing the response submissions. Rather, it is meant to support the ONC-ACBs' other responsibility in § 170.550(l) to ensure that developers of certified health IT are meeting their responsibilities under the Conditions and Maintenance of Certification requirements before issuing a certification.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters, including developers of certified health IT, opposed our expectation related to § 170.407(b)(1) in the HTI-1 Proposed Rule (88 FR 23847) that health IT developers would need to renegotiate their contracts or business agreements that inhibit their ability to collect data from their customers in order to comply with this requirement. Commenters stated that this expectation to renegotiate contracts or business agreements was unreasonable, not feasible, or overly burdensome.
                    </P>
                    <P>Two commenters questioned the authority of ONC to require developers of certified health IT to renegotiate contracts or business agreements in order to gain access to customer data for the Insights Condition. Two developers of certified health IT commented that they experienced challenges in soliciting participation from customers in data collection for the Real World Testing Condition despite their efforts. One commenter noted that it is not feasible to require a renegotiation of client contracts specific to only one term without reopening renegotiation of all contract terms. One commenter stated the amount of time that finding, assessing, negotiating, and re-finalizing a contract is unreasonable in the proposed timeframe.</P>
                    <P>Several developers of certified health IT commented that ONC should require a good faith effort by developers to engage their customers to participate. Also, commenters suggested ONC include language in the Insights Condition that allows for exclusions or other flexibilities from reporting where health IT developers have been unable to obtain data for measures despite good faith efforts.</P>
                    <P>Several developers of certified health IT further commented that establishing a minimum threshold of customers is not a viable way to address their concerns. One developer of certified health IT commented that ONC should set the expectation that health IT developers request participation in data collection under the Insights Condition from all of their U.S.-based customers of certified health IT and report all of the data from participants who agree, as well as what percentage of their total customers this represents. One commenter sought clarification from ONC on whether there is an expectation that developers of certified health IT obtain numerator and denominator data from every U.S. customer using a product or only those customers agreeing to participate.</P>
                    <P>One commenter noted that time and cost estimates were not included in the Regulatory Impact Analysis for effort necessary from developers of certified health IT, or health systems, for contract renegotiation expectations related to § 170.407(b)(1). The commenter further noted that effort from both health IT developers and health systems would be necessary for each renegotiated contract.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the commenters' concerns regarding the feasibility of requiring developers of certified health IT to renegotiate contracts, when needed, with their customers to comply with the Insights Condition requirements. In response to public comment, we have removed this proposed requirement. In a scenario where a developer of certified health IT has contracts or business agreements with a customer that inhibit the health IT developer's ability to comply with the Insights Condition requirements, the health IT developer may exclude that customer's data for reporting under the Insights Condition.
                    </P>
                    <P>
                        In § 170.407(b)(1) in the HTI-1 Proposed Rule (88 FR 23847) we proposed that health IT developers provide us metrics based upon data from all their customers. In response to health IT developers expressing concerns regarding the difficulty in obtaining data from clients whose contracts would require updating to access the needed data, we have scaled back our requirement for health IT developers to provide complete data on all clients. In addition to the data on available clients that they report, health IT developers will provide ONC with information on the degree to which the data they are submitting is complete. We emphasize that the Insights Condition fulfills the Cures Act specified requirements in section 4002(c) to establish an Electronic Health Record (EHR) Reporting Program to provide transparent reporting on certified health IT with respect to all certified technology offered by a health IT developer, and therefore, health IT developers should be as inclusive as possible.
                        <PRTPAGE P="1348"/>
                    </P>
                    <P>Based upon the suggestion we received via comments, we have finalized in § 170.407(a)(1)(i)(C) that health IT developers will report the percentage of their total customers, as represented by hospitals for inpatient products and clinician users for their outpatient products, that are included in their reported data for each metric for which they submit a response. The percentage of health care providers that are represented in the data provides transparency on the degree to which the data are complete. Specifically, we seek to determine whether the aggregated data that we receive from all health IT developers will produce nationally representative measures will be critical to generate and report the derived statistics and explain the results. For example, if the percentage of total customers represented is low across many health IT developers, then we would know that the data are incomplete. This in turn, would enable ONC to consider whether it would be valid to generate statistics at the national level. Overall, this information shall help ONC interpret the results and allow us to assess the degree to which the data are complete.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters opposed our proposal in § 170.407(b)(1)(i) for the first Insights Condition reporting period to begin in April 2024. Some commenters stated the timeline was unrealistic, not feasible, or impossible given timeframes to develop, deploy, test, and build the capability to compile the data. Commenters offered various alternative timelines for the first Insights Condition reporting period to begin. Several commenters requested delaying the first reporting period to begin in calendar year 2025, such as in January, April, or October of 2025. Several commenters requested delaying the first reporting period to begin in calendar year 2026. Some commenters requested delaying the first reporting period to begin 18 months after the final rule publication. One commenter requested ONC reconsider implementation over a four- or five-year timeframe. One commenter suggested longer timelines to ensure measures are validated before phasing in new measures.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the feedback and have revised the Insights Condition timelines. We have finalized in § 170.407(b)(1)(i) to delay the first reporting period to allow developers of certified health IT adequate time to develop and implement the Insights Condition measures and related metrics. We have finalized that the first data collection period will be January to December 2026, followed by the submission of the first phase of measures and related metrics due in July of 2027. This represents “year one” of the Insights Condition requirements. Reporting is on an annual basis thereafter. We have further extended our phased approach to measure requirements, including layering complexity associated with certain measures over the course of three years, so that certain measures (and related metrics) start in year one, while other measures or stratifications to existing measures begin in subsequent years. We have finalized “year 2” measures and related metrics start data collection in calendar year 2027, with responses due in July 2028, and annually thereafter. Finally, we have finalized “year 3” measures and related metrics start data collection in calendar year 2028, with responses due in July 2029 and annually thereafter. The phasing of the measures and related metrics are illustrated in the table in this section of the preamble.
                    </P>
                    <P>We also appreciate the commenter's concern for needing additional time to assess measure validity. Our revised approach of phasing in more complex aspects of each of the measures enables reviewing baseline measures before adding complexity. Furthermore, our revised approach provides additional time for measure development and implementation and will allow us to apply lessons learned from the smaller set of measures to inform the implementation of next set.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Most commenters opposed our proposal in § 170.407(b)(1) to require the frequency of semiannual (
                        <E T="03">i.e.,</E>
                         every six months) data collection and reporting under the Insights Condition. Most commenters suggested an annual frequency of data collection and reporting to reduce burden. Many of these commenters suggested using a calendar-year reporting period with reporting to occur mid-year to better align with the CMS Promoting Interoperability Programs and the Real World Testing Condition, and to avoid other April/October requirements for Attestations submissions. One health system commenter suggested an annual reporting period that does not overlap with clinical quality measure reporting schedules. One commenter stated that semiannual reporting would require two product upgrades within a one-year timeframe and that their customers would not be willing to comply. Three commenters supported our proposal to require semiannual (
                        <E T="03">i.e.,</E>
                         every six months) data collection and reporting in April and October. One health IT developer commented the proposed six-month intervals are feasible with current technology and not overly burdensome to health IT developers. Commenters supported our proposal in § 170.407(b)(1) for six months to assemble and assess data collected prior to reporting under the Insights Condition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback on reporting frequency and the concerns expressed related to burden. To address these concerns, we have finalized to reduce the reporting frequency to annually (once per year) in § 170.407(b), on a calendar year cycle, with data collection to be completed from January to December. We have maintained the six-month data assembly period, such that reports for a given calendar year will be due to be submitted in July of the following calendar year.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters requested clarification on whether developers of certified health IT have the flexibility to reuse the Insights Condition reporting measurements and outputs for their Real World Testing plans and results.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the commenters request for clarity. We appreciate that the data collected related to the Insights Condition and Real World Testing could overlap. Therefore, developers of certified health IT can choose to repurpose the Insights Condition reporting measurements and/or data as part of their Real World Testing plans and results.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One health IT developer suggested that ONC apply its experience with Real World Testing to reduce measure ambiguity and provide Real World Testing reports as examples for health IT developers to use in planning for the Insights Condition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree with the commenter that the Real World Testing Condition provides relevant experience for health IT developers. We considered Real World Testing Condition reports in developing our proposals for the Insights Condition and intend to provide examples. We plan to leverage a system linked to the CHPL for reporting to make the process similar to other certification related processes. We will use web-based forms within that system for submission and plan to provide templates for health IT developers to use in their data submission for the Insights Condition. The templates will enable health IT developers to submit the data (as noted in the 88 FR 23847) in a machine-readable format, such as JavaScript Object Notation (JSON). We also intend to provide educational sessions and resources for health IT developers to support electronic reporting of the metrics and related documentation.
                        <PRTPAGE P="1349"/>
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters recommended that ONC expand its governance structure to include patients and other clinicians in reviewing Insights Condition and Real World Testing results to identify new opportunities for action.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for the input. As described in our HTI-1 Proposed Rule, ONC, and our contractor, conducted various engagement efforts with a variety of groups having potential interests in the Insights Condition. This engagement process 
                        <SU>219</SU>
                        <FTREF/>
                         included a request for information by ONC, public forums, listening sessions, and discussions with experts and key groups, including health IT end users (
                        <E T="03">e.g.,</E>
                         clinicians) and health IT developers. In addition to this engagement and public comments, the Health IT Advisory Committee (HITAC), which includes patient advocates and clinicians, provided recommendations 
                        <SU>220</SU>
                        <FTREF/>
                         to ONC that informed the Insights Condition. We will continue to look for opportunities to obtain input from a variety of perspectives, including patients and clinicians, on the Insights Condition.
                    </P>
                    <FTNT>
                        <P>
                            <SU>219</SU>
                             
                            <E T="03">https://www.urban.org/research/publication/what-comparative-information-needed-ehr-reporting-program.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>220</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2022-07/2021-09-09_EHRRP_TF_2021__HITAC%20Recommendations_Report_signed_508_Edit.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One health care provider organization recommended that ONC make the Insights Condition metrics easily accessible to users of certified health IT and to the public. One health IT developer sought clarification from ONC if we intend to calculate and display percentages using the reported numerators and denominators across the universe of certified health IT that reported for a given measure, or if we intend to calculate and display metrics at the developer or product level. Another commenter encouraged ONC and developers of certified health IT under the Insights Condition to evaluate measure reliability and validity of the reported data before publicly reporting.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for the opportunity to clarify how ONC will calculate and display the Insights Condition metrics. In accordance with the Cures Act, we intend to make responses (the metrics and required documentation) to the Insights Condition publicly available on an ONC website. Prior to publicly releasing the data or publishing metrics, we will review and analyze the data to assess completeness and generalizability, which relate to the reliability and validity of the data. After this analysis, we will determine what level(s) the calculated metrics would be displayed, such as at the product, developer and/or national level. The aggregated data that is reported needs to have an adequate number of data points at any given level to make sure the metrics displayed are valid and reliable.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended that ONC create a public list of the certification status of health IT developers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for this input, and note that ONC maintains the Certified Health IT Products List (CHPL) at 
                        <E T="03">https://chpl.healthit.gov/,</E>
                         which is a comprehensive and authoritative listing of all certified health information technology that have been successfully tested and certified by the Program and includes current certification statuses.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested requiring health IT developers to report on whether the certified health IT is hosted by the health IT developer or installed locally under the direct control of the user. Further, the commenter noted that this information may provide insight into usage patterns and adoption of cloud services and other technology that can inform HHS regulations.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for this suggestion, and we agree that this data element could be useful and informative in assessing the state of the certified health IT marketplace. We may consider this for future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter stated that ONC-ACBs will need more detailed information on the degree of surveillance and validation that ONC-ACBs will need to provide in support of the Insights Condition reporting process in order to plan appropriately.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Similar to other Conditions and Maintenance of Certification requirements, we will provide additional guidance to ONC-ACBs regarding their role and requirements related to oversight of the Insights Condition as the workflow and reporting systems for the Insights Condition are developed and finalized.
                    </P>
                    <HD SOURCE="HD3">G. Requests for Information</HD>
                    <HD SOURCE="HD3">1. Laboratory Data Interoperability Request for Information</HD>
                    <P>We sought public feedback in the HTI-1 Proposed Rule (88 FR 23848) that may be used to inform a study and report required by Division FF, Title II, Subtitle B, Ch. 2, Section 2213(b) of the Consolidated Appropriations Act, 2023 (Pub. L. 117-328, Dec. 29, 2022), or future rulemaking regarding the adoption of standards and certification criteria to advance laboratory data interoperability and exchange.</P>
                    <P>We sought public comment generally on any topics identified in the Consolidated Appropriations Act, 2023, Section 2213(b) study on the use of standards for electronic ordering and reporting of laboratory test results, such as the use of health IT standards by clinical laboratories, use of such standards by laboratories and their effect on the interoperability of laboratory data with public health systems, including any challenges of the types identified above. We also sought comment on whether ONC should adopt additional standards and laboratory-related certification criteria as part of the Program. We received many valuable comments on this RFI. We appreciate the input provided by commenters and may consider their input to inform a future rulemaking.</P>
                    <HD SOURCE="HD3">2. Request for Information on Pharmacy Interoperability Functionality Within the ONC Health IT Certification Program Including Real-Time Prescription Benefit Capabilities</HD>
                    <P>Section 119 of Title I, Division CC of the Consolidated Appropriations Act, 2021, (Pub. L. 116-260) (CAA), requires PDP sponsors of prescription drug plans to implement one or more real-time benefit tools (RTBTs) after the Secretary has adopted a standard for RTBTs and at a time determined appropriate by the Secretary. The law specified that a qualifying RTBT must meet technical standards named by the Secretary, in consultation with ONC. Section 119(b)(3) also amended the definition of a “qualified electronic health record” in section 3000(13) of the PHSA to specify that a qualified electronic health record must include or be capable of including an RTBT. In the 2014 Edition Final Rule, ONC established the term “Base EHR,” based on the “Qualified EHR” definition, for use within the Program (77 FR 54262).</P>
                    <P>
                        As stated in the HTI-1 Proposed Rule (88 FR 23848), we intend to propose in future rulemaking the establishment of a real-time prescription benefit health IT certification criterion within the Program and include this criterion in the Base EHR definition in § 170.102. We intend to propose a criterion that would certify health IT to enable a provider to view within the electronic prescribing workflow at the point of care patient-specific benefit, estimated cost information, and viable alternatives. We are also considering a proposal to adopt and reference the National Council for Prescription Drug Programs (NCPDP) Real-Time Prescription Benefit (RTPB) standard version 12 as part of the potential 
                        <PRTPAGE P="1350"/>
                        certification criterion.
                        <SU>221</SU>
                        <FTREF/>
                         This standard would enable the exchange of patient eligibility, product coverage, and benefit financials for a chosen product and pharmacy, and identify coverage restrictions and alternatives when they exist.
                    </P>
                    <FTNT>
                        <P>
                            <SU>221</SU>
                             For further information about implementing the NCPDP RTPB standard version 12, see resources at 
                            <E T="03">https://standards.ncpdp.org/Access-to-Standards.aspx.</E>
                        </P>
                    </FTNT>
                    <P>While we believe that implementing RTBT functionality required for inclusion in the Program under the CAA would be an important step towards improving prescribing experiences for providers and patients, we recognize that it is only one of a series of capabilities that are part of a comprehensive workflow for evaluating and prescribing medications (88 FR 23849).</P>
                    <P>Today, the Program addresses these additional capabilities in a limited manner. For instance, in the ONC Cures Act Final Rule, ONC adopted NCPDP SCRIPT standard version 2017071 and updated the “electronic prescribing” certification criterion in § 170.315(b)(3)(ii) to reflect this standard, including specifying electronic prior authorization transactions supported by the standard as optional transactions, which health IT developers can elect to have explicitly tested, or not, as part of certification of a product to § 170.315(b)(3) (85 FR 25680).</P>
                    <P>A “drug-formulary and preferred drug list checks” certification criterion had been established for the 2015 Edition in § 170.315(a)(10) but was later removed from the Program by the ONC Cures Act Final Rule (85 FR 25660). ONC removed the criterion due to the lack of associated interoperability standards and to reduce certification burden on developers as this functionality had been widely adopted across industry.</P>
                    <P>We requested comment in the HTI-1 Proposed Rule (88 FR 23849) from the public about specific issues related to establishing a certification criterion using NCPDP RTPB standard version 12 and other potential actions that could support complementary and interoperable workflows. Given the statutory definition in PHSA § 3000(13) of “qualified electronic health record” as an electronic record of health-related information on an individual that includes, or is capable of including, RTBT functionality, we sought to understand whether ONC should offer or require certification of other capabilities to optimize the value of real-time prescription benefit capabilities to clinicians and patients.</P>
                    <P>We requested input on how developers of certified health IT may be able to support drug price transparency, patient choice, and meet other market demands while ensuring reliable and trusted performance. We received many insightful comments on this RFI. We appreciate the input provided by commenters and may consider their input to inform a future rulemaking.</P>
                    <HD SOURCE="HD3">3. FHIR Standard</HD>
                    <P>This request for information included in the HTI-1 Proposed Rule (88 FR 23855) focused on the FHIR standard for APIs (including FHIR Subscriptions, CDS Hooks, FHIR standards for scheduling, and SMART Health Links) and aligned with our aims of advancing interoperability through the use of APIs for treatment, payment and operations use cases. We welcomed technical and policy comments as we consider the potential applicability of these standards and specifications. We received many insightful comments on this RFI. We appreciate the input provided by commenters and may consider their input to inform a future rulemaking.</P>
                    <HD SOURCE="HD1">IV. Information Blocking Enhancements</HD>
                    <P>
                        In the HTI-1 Proposed Rule (88 FR 23746), we proposed enhancements to support information sharing under the information blocking regulations and to promote innovation and competition, as well as address market consolidation (
                        <E T="03">see</E>
                         Executive Summary discussion at 88 FR 23749 and 88 FR 23754 through 23755; 
                        <E T="03">see also</E>
                         preamble discussion in section IV of the HTI-1 Proposed Rule at 88 FR 23857 through 23873). We proposed new and revised definitions of terms for purposes of the information blocking regulations in 45 CFR part 171. The revisions to definitions included, as discussed in section IV.B.3, the removal of references to a period of time now passed in the information blocking definition (§ 171.103). We proposed (as discussed in IV.B.3 of this preamble) to remove reference to the period of time, now passed, from the exception in 45 CFR 171.301. We proposed, consequently, to rename the “Content and Manner Exception” to simply the “Manner Exception.” Each of these proposals is discussed, and public comments received on each proposal summarized, in section IV.B of this preamble.
                    </P>
                    <P>
                        We proposed enhancements to certain information blocking exceptions that had been established by the ONC Cures Act Final Rule (85 FR 25642). We proposed to clarify the 
                        <E T="03">uncontrollable events</E>
                         condition of the Infeasibility Exception (§ 171.204) to make it clear that an uncontrollable event must in fact have affected the actor's ability to fulfill requests for access, exchange, or use of EHI (for a more detailed summary, please see section IV.C.1.a of this preamble). We also proposed to create new conditions for (options through which to satisfy) the Infeasibility Exception when an actor has exhausted the § 171.301 Manner Exception and, separately, when a third party requests to modify EHI held by the actor. These conditions are discussed in sections IV.C.1.b and IV.C.1.c of this preamble. As discussed in section IV.C.2 of this preamble, we proposed to add a 
                        <E T="03">TEFCA manner</E>
                         condition to the proposed revised and renamed Manner Exception codified in 45 CFR 171.301 (
                        <E T="03">see</E>
                         88 FR 23872 through 23873).
                    </P>
                    <P>The HTI-1 Proposed Rule included (at 88 FR 23873 through 88 FR 23876) three information blocking requests for information (RFIs). The first of these RFIs sought information on potential additional exclusions from the definition of “offer health IT.” The second sought information on possible additional TEFCA reasonable and necessary activities. The third sought information on health IT capabilities for data segmentation and user or patient access. We discuss these requests for information below, in section IV.D.1 through IV.D.3 of this preamble.</P>
                    <HD SOURCE="HD2">A. General Comments</HD>
                    <P>
                        <E T="03">Comments.</E>
                         In general, commenters expressed support for the proposed enhancements and for updating the regulations over time to improve clarity or reduce burdens for actors while continuing to encourage interoperable access, exchange, and use of EHI to the full extent permitted by applicable law and consistent with individual patients' privacy preferences. Some commenters made suggestions, recommendations, or requests for additional guidance, information and educational resources, or for other tools to help actors appropriately share information and avoid conduct that would be considered “information blocking” (as defined in 45 CFR 171.103).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support expressed by many commenters. We include below additional explanation of provisions of this final rule. Requests, recommendations, or suggestions that we provide additional guidance, resources, or tools relevant to information blocking are appreciated. As part of our ongoing outreach and education efforts, all feedback and information we receive helps to inform our consideration and development of resources such as webinar 
                        <PRTPAGE P="1351"/>
                        presentations, fact sheets, and frequently asked questions (FAQs).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several comments advocated for specific changes to the information blocking regulations, to other HHS regulations, or to state law. For example, a commenter advocated “aligning HIPAA rules, 42 CFR part 2 requirements, and other state and federal laws with information blocking regulations.” Another commenter stated that “ONC needs to clarify the national requirements for production of complete medical records, especially absolute transparency on corrections, deletions, delayed entries, and original content, upon ordinary request.” A commenter indicated health IT users may mis-apply the designated record set (DRS) definition to electronic records and stated that ONC “needs to consider discouraging inappropriate DRS definition-based information blocking of complete medical records through significant, powerful disincentives.” One commenter advocated for ONC to narrow the 
                        <E T="03">health information network</E>
                         definition “and clearly state in the regulatory text payers are not included in this definition and thus are not subject to the information blocking provision.” Another commenter expressed a view that specifying in the information blocking definition's regulatory text the persons whose records access can be affected by a practice would make the rule stronger.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Comments related to the following are outside of the scope of the information blocking provisions of this rulemaking: establishment of health care provider disincentives for information blocking conduct; changes to HHS regulations outside 45 CFR part 171; adoption of requirements for creation or retention of specific metadata by all health care providers nationwide; and any change to any state or tribal law. However, comments recommending policy changes outside the scope of this rule are part of the rulemaking record, and we may refer to them as an information source when assessing potential future rulemaking or outreach and education activities.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A substantial number of comments expressed concerns about a perceived conflict between the goals of maximizing information sharing and appropriately protecting patients' privacy interests. These comments generally associated these concerns with specific policy recommendations, including the creation of new information blocking exception(s). Some commenters suggested that some § 171.102 actors may believe they have no option under information blocking regulations but to enable the access, exchange, or use of all EHI in all situations—including those where only some of the EHI can be used or disclosed consistent with privacy laws or the patient's individual privacy preferences. A few of these commenters specifically noted sensitive information or information associated with sensitive types of care, such as reproductive or behavioral health care.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Some of the policy recommendations that commenters offered to address these concerns, such as to establish new exceptions or implement revisions beyond anything described in the HTI-1 Proposed Rule, were outside the scope of this rulemaking. Some provisions advocated by commenters appear to duplicate provisions already in place, such as provisions of the Privacy Exception (§ 171.202) and the Infeasibility Exception (§ 171.204). The expressed concerns and advocacy of duplicative policy provisions suggest it may be helpful to highlight here certain aspects of how the information blocking regulations currently operate.
                    </P>
                    <P>
                        Where applicable law prohibits a specific access, exchange, or use of information, the information blocking regulations consider the practice of complying with such laws to be “required by law.” Practices that are “required by law” are not considered “information blocking” (
                        <E T="03">see</E>
                         the statutory information blocking definition in section 3022(a)(1) of the PHSA and the discussion in the ONC Cures Act Final Rule at 85 FR 25794). For example, when the HIPAA Privacy Rule prohibits a covered entity or business associate from disclosing PHI, an actor who is also a covered entity or business associate 
                        <E T="03">can</E>
                         comply fully with the HIPAA Privacy Rule without implicating the information blocking regulations. For another example, a § 171.102 actor subject to a state or tribal law that expressly prohibits a certain access, exchange, or use of EHI 
                        <E T="03">can</E>
                         comply fully with that state or tribal law without implicating the information blocking regulations.
                    </P>
                    <P>We recognize that even where federal, state, or tribal law does not expressly prohibit the actor from fulfilling a request to access, exchange, or use EHI, or require an actor to engage in particular privacy-protective practices, an actor may nevertheless wish to engage in practices likely to interfere with access, exchange, or use in order to honor their patients' privacy preferences. Actors covered by the information blocking regulations—health IT developers of certified health IT, health information networks or health information exchanges (HIN/HIEs), and health care providers—may seek certainty that the privacy-protective practices that are not required of them by law, but in which they choose to engage, will not meet the definition of information blocking.</P>
                    <P>
                        In the ONC Cures Act Final Rule, we established the Privacy Exception (45 CFR 171.202) to ensure that actors can engage in reasonable and necessary practices that advance the privacy interests of individuals (
                        <E T="03">see</E>
                         85 FR 25845 through 25859) without committing “information blocking” as defined in section 3022(a)(1) of the PHSA and 45 CFR 171.103.
                    </P>
                    <P>For example, the information blocking regulations in 45 CFR part 171 accommodate the fact that, in various circumstances, other applicable law (federal, state, or tribal) does not permit EHI to be used or disclosed unless certain preconditions are met. The Precondition Not Satisfied (45 CFR 171.202(b)) sub-exception of the Privacy Exception outlines a framework for actors to follow to be assured their practices of not fulfilling requests to access, exchange, or use EHI will not constitute information blocking when a precondition of applicable state, tribal, or federal law has not been satisfied.</P>
                    <P>In addition, for purposes of the Precondition Not Satisfied sub-exception, an actor operating under multiple state laws, or state and tribal laws, with inconsistent preconditions for EHI disclosures may choose to adopt uniform policies and procedures to address the more restrictive preconditions (45 CFR 171.202(b)(3)).</P>
                    <P>
                        Examples that highlight the alignment between the HIPAA Privacy Rule and the information blocking regulations are included in the “HIPAA Privacy Rule and Disclosures of Information Relating to Reproductive Health Care” guidance issued by the Office for Civil Rights. As outlined in this guidance, there are certain preconditions that must be met before disclosures about reproductive health care can be made by health care provider workforce members, including to law enforcement officials. For instance, if a law enforcement official requests records of abortions from a reproductive health care clinic: “If the request is not accompanied by a court order or other mandate enforceable in a court of law, the Privacy Rule would not permit the clinic to disclose PHI in response to the request. Therefore, such a disclosure would be impermissible and constitute a breach of unsecured PHI requiring notification to HHS and the individual affected.” In this example, federal law does not permit the disclosure of EHI unless certain requirements are met, and therefore, the 
                        <PRTPAGE P="1352"/>
                        actor's practice not to disclose EHI would not be information blocking. We note that this is just one example of how the HIPAA Privacy Rule gives individuals confidence that their protected health information, including information relating to abortion and other sexual and reproductive health care, will be kept private. Please see the guidance from the Office for Civil Rights for additional information and examples.
                        <SU>222</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>222</SU>
                             
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/phi-reproductive-health/index.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        We also note that information blocking regulations in 45 CFR part 171 accommodate an actor, if they so choose, agreeing to an individual's request for restrictions on sharing of the individual's EHI beyond the restrictions imposed by applicable law(s). Specifically, where the requirements specified in 45 CFR 171.202(e) are met, the Respecting an Individual's Request Not to Share Information (§ 171.202(e)) sub-exception of the Privacy Exception applies to an actor's practice of honoring an individual's request not to provide access, exchange, or use of the individual's EHI. This aligns with the individual's right to request a restriction on certain uses and disclosures of their PHI under the HIPAA Privacy Rule (45 CFR 164.522(a)(1)), to which an actor that is a covered entity 
                        <E T="03">may choose</E>
                         to agree but is 
                        <E T="03">not required</E>
                         by the HIPAA Privacy Rule to agree.
                    </P>
                    <P>In scenarios where a § 171.102 actor that is also subject to the HIPAA Privacy Rule must agree to the request of an individual to restrict disclosure of PHI as provided in 45 CFR 164.522(a)(1)(vi), the actor's practice of agreeing to the request and complying with all requirements of 45 CFR 164.522 applicable to such requests and restrictions is, in our view, a practice that is “required by law.” We reiterate that practices that are required by law are excluded from the statutory (PHSA section 3022(a)(1)) as well as the regulatory (45 CFR 171.103) definition of information blocking without needing to also satisfy any of the 45 CFR part 171 exceptions. Therefore, when a § 171.102 actor that is also a HIPAA covered entity engages in a practice of complying with all requirements of 45 CFR 164.522 that are applicable to requests to which a covered entity must agree (as provided in 45 CFR 164.522(a)(1)(vi)) then that actor would not need to also satisfy the Respecting an Individual's Request Not to Share Information (45 CFR 171.202(e)) sub-exception of the Privacy Exception in order for that practice to not be considered information blocking. The practice would be excluded from the definition of information blocking because it would be “required by law” and, therefore, an information blocking exception for the practice would not be needed.</P>
                    <P>
                        We refer commenters and other readers interested in learning more about the interaction of the information blocking regulations with the HIPAA Rules and other laws protecting individuals' privacy interests to the discussion of the Privacy Exception in the ONC Cures Act Final Rule (85 FR 25642, 85 FR 25845 through 25859). We also highlight the availability of additional resources through our website (start at: 
                        <E T="03">https://www.healthit.gov/topic/information-blocking</E>
                        ). Resources focused on how the information blocking rules work in harmony with privacy laws include, for example, an ONC Health IT buzz blog post titled “
                        <E T="03">Information Blocking Regulations Work in Concert with HIPAA Rules and Other Privacy Laws to Support Health Information Privacy</E>
                        ” 
                        <SU>223</SU>
                        <FTREF/>
                         and the following three frequently asked questions (FAQs) highlighting how information blocking regulations work in tandem with the HIPAA Privacy Rule and other privacy protective laws:
                    </P>
                    <FTNT>
                        <P>
                            <SU>223</SU>
                             
                            <E T="03">https://www.healthit.gov/buzz-blog/information-blocking/information-blocking-regulations-work-in-concert-with-hipaa-rules-and-other-privacy-laws-to-support-health-information-privacy.</E>
                             (Retrieved 7/12/2023.)
                        </P>
                    </FTNT>
                    <P>
                        • Would it be information blocking if an actor does not fulfill a request to access, exchange, or use EHI in order to comply with federal privacy laws that require certain conditions to have been met prior to disclosure? 
                        <SU>224</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>224</SU>
                             Information blocking FAQ identifier: IB.FAQ48.1.2023APR. URL: 
                            <E T="03">https://www.healthit.gov/faq/would-it-be-information-blocking-if-actor-does-not-fulfill-request-access-exchange-or-use-ehi.</E>
                             (Retrieved 7/12/2023.)
                        </P>
                    </FTNT>
                    <P>
                        • If an actor, such as a health care provider, operates in more than one state, is it consistent with the information blocking regulations for the health care provider to implement practices to uniformly follow the state law that is the most privacy protective (more restrictive) across all the other states in which it operates? 
                        <SU>225</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>225</SU>
                             Information blocking FAQ identifier: IB.FAQ49.1.2023APR. URL: 
                            <E T="03">https://www.healthit.gov/faq/if-actor-such-health-care-provider-operates-more-one-state-it-consistent-information-blocking.</E>
                             (Retrieved 7/12/2023.)
                        </P>
                    </FTNT>
                    <P>
                        • If an individual requests that their EHI not be disclosed, is it information blocking if an actor does not disclose the EHI based on the individual's request? 
                        <SU>226</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>226</SU>
                             Information blocking FAQ identifier: IB.FAQ47.1.2023APR. URL: 
                            <E T="03">https://www.healthit.gov/faq/if-individual-requests-their-ehi-not-be-disclosed-it-information-blocking-if-actor-does-not.</E>
                             (Retrieved 7/12/2023.)
                        </P>
                    </FTNT>
                    <P>
                        The Infeasibility Exception may also be applicable to matters of patient privacy preferences. Established by the ONC Cures Act Final Rule, the Infeasibility Exception (45 CFR 171.204) applies when an actor's practice meets one of the conditions set forth in § 171.204(a) and also meets the condition in § 171.204(b) (
                        <E T="03">see</E>
                         85 FR 25958, 
                        <E T="03">see also</E>
                         preamble discussion at 85 FR 25866 through 25870). The 
                        <E T="03">segmentation</E>
                         condition of the Infeasibility Exception (§ 171.204(a)(2)) can be met in conjunction with other exceptions to provide actors assurance that their practice does not constitute information blocking. The 
                        <E T="03">segmentation</E>
                         condition is applicable when the actor cannot fulfill the request for access, exchange, or use of EHI because the actor cannot unambiguously segment the requested EHI from EHI that:
                    </P>
                    <P>
                        • cannot be made available due to the individual's preference (such as where the individual has requested that the EHI not be shared with a specific person(s), for a specific purpose(s), or both); 
                        <SU>227</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>227</SU>
                             We use “individual” here, and for purposes of § 171.204 in general, as it is defined in § 171.202(a).
                        </P>
                    </FTNT>
                    <P>• cannot be made available by law, for example, the HIPAA Privacy Rule, other federal law, or applicable state or tribal law does not permit the EHI to be made available to the person seeking it, for the purpose it is sought, or both; or</P>
                    <P>• may be withheld in accordance with the Preventing Harm Exception (45 CFR 171.201).</P>
                    <P>
                        Applicable law may restrict providing certain types of EHI to a person or class of persons, for a specific purpose, or a combination of types of persons and specific purposes. For example, federal, state, or tribal law may require that certain information not be accessed, used, or exchanged by the person seeking it, for the purpose it is sought, or both. As we discuss above, an actor can, without engaging in “information blocking,” withhold information as required by law or withhold information by meeting the Pre-condition Not Satisfied sub-exception. Similarly, an individual (
                        <E T="03">see</E>
                         definition of “
                        <E T="03">individual</E>
                        ” in § 171.202(a)) may express a preference that some or all of the EHI for a particular patient not be shared with a specific person(s), for a specific purpose(s), or a specific combination of person(s) and purpose(s). Such a preference could be expressed, for example, by the individual making a request that a HIPAA covered entity restrict uses and disclosures of their PHI that § 164.522 
                        <PRTPAGE P="1353"/>
                        requires covered entities to permit an individual to make. As we discuss above, and in accordance with the § 171.202(e) Respecting an Individual's Request Not to Share Information sub-exception, an actor may withhold information that a patient has requested the actor not share.
                    </P>
                    <P>
                        The example above illustrates a specific alignment between the information blocking regulations and HIPAA Privacy Rule. However, the § 171.202(e) sub-exception's alignment with the individual's right under the HIPAA Privacy Rule to request restrictions does not limit the sub-exception's availability to actors who are also subject to the HIPAA Privacy Rule's requirements. Nothing in the § 171.202(e) sub-exception limits its availability based on whether the actor is a HIPAA covered entity or business associate that must comply with the HIPAA Privacy Rule. Likewise, § 171.202(e) does not focus on whether the individual requested restrictions under any specific provision of the HIPAA Privacy Rule. Therefore, for purposes of the information blocking regulations, the § 171.202(e) Respecting an Individual's Request Not to Share Information sub-exception can be satisfied by 
                        <E T="03">any</E>
                         actor who chooses to meet the requirements of the sub-exception.
                    </P>
                    <P>
                        We recognize many actors may currently be unable to unambiguously segment reproductive health and behavioral health information indicated by some commenters on the information blocking provisions as sensitive information, as well as gender-affirming care information, from other EHI. These are also examples of types of information for which individuals may be likely to request restrictions on uses or disclosure. These are, however, not the only types of information to which the Infeasibility Exception's 
                        <E T="03">segmentation</E>
                         condition might apply. As we noted in the HTI-1 Proposed Rule, a health care provider might choose to honor a patient's request for restrictions on sharing of their EHI even if the provider did not 
                        <E T="03">know</E>
                         the patient's specific reasons for the request. The Respecting An Individual's Request Not To Share Information sub-exception (§ 171.202(e)) does not specify that the individual requesting restrictions should have particular reasons for requesting restrictions, or be required to share their reasoning with the health care provider or other actor of whom they make the request (88 FR 23874).
                    </P>
                    <P>
                        Where an actor engaging in a practice that is not (or practices that are not) fully covered by a single exception seeks certainty that such practices do not constitute information blocking, the actor could choose to satisfy several applicable exceptions that, in complement, do fully cover their practices. Applicable exceptions, and combinations of exceptions, will vary based on the actor's specific practice and particular facts and circumstances in which they engage and the practices for which the actor seeks the certainty offered by information blocking exceptions.
                        <SU>228</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>228</SU>
                             It is important to remember that the information blocking exceptions defined in 45 CFR part 171 subparts B and C are voluntary, offering actors certainty that any practice meeting the conditions of one or more exceptions would not be considered information blocking. An actor's practice that does not meet the conditions of an exception would not automatically constitute information blocking. 
                            <E T="03">See, e.g.,</E>
                             IB.FAQ29.1.2020NOV, URL: 
                            <E T="03">https://www.healthit.gov/faq/if-actor-does-not-fulfill-request-access-exchange-and-use-ehi-any-manner-requested-they-have.</E>
                             (Retrieved 7/12/2023.)
                        </P>
                    </FTNT>
                    <P>
                        In various circumstances, an actor may wish to engage in one or more practice(s) that are covered in part, but not fully covered, by the Privacy Exception (§ 171.202) or the Preventing Harm Exception (§ 171.201). In some of these situations, such an actor may want to consider the potential certainty that could be available by satisfying a combination of the Infeasibility Exception (§ 171.204) with the Privacy Exception (§ 171.202) or with the Preventing Harm Exception (§ 171.201), or any combination of multiple exceptions applicable to the specific practice in which the actor engages. We provide the following example to illustrate how the use of a combination of exceptions might occur. We note that we have intentionally omitted from this example any consideration of why the individual may request, or why the actor may have chosen to agree to the individual's request. This is because the § 171.202(e) sub-exception's application is not limited based on what particular reasons an individual may have for requesting restrictions of any or all of their EHI, and does not specify that an actor must have specific reasons for choosing to grant rather than deny an individual's request for restrictions. However, as noted above, these exceptions could be exercised, separately or together, when an individual requests certain information (
                        <E T="03">e.g.,</E>
                         reproductive health, behavioral health, or gender-affirming care information) not be shared or when such information cannot be unambiguously segmented from other EHI from the reasons noted above.
                    </P>
                    <P>
                        An individual makes a request of an actor not to share certain EHI. The actor agrees to the request, documents the request, implements the request, and does not otherwise terminate the request. After the actor agrees to the individual's request not to share information, the actor receives a request for the individual's EHI that encompasses information the individual requested that the actor not share. The actor determines that responding to the request is not prohibited by applicable law. The actor then determines that the actor has the technical ability to segment out some, but not all, of the requested EHI from the EHI subject to the individual's request not to share. The actor notifies the requestor in writing in 10 business days from the receipt of the request that the actor cannot unambiguously segment the EHI from the EHI that the actor cannot share for reasons consistent with the § 171.204(a)(2) 
                        <E T="03">segmentation</E>
                         condition. The actor provides the requestor with EHI the actor can unambiguously segment from the EHI that is subject to the individual's request, and the actor does not provide the requester with certain EHI that the actor cannot unambiguously segment from the EHI subject to the individual's request.
                    </P>
                    <P>
                        • For purposes of this example, the actor has two exceptions available. First, the actor has received an individual's request not to share information, elected to grant the individual's requested restriction on access, exchange, or use of EHI, and met the requirements of the § 171.202(e) Respecting an Individual's Request Not to Share Information sub-exception of the Privacy Exception. (Note: for purposes of the § 171.202(e) Respecting an Individual's Request Not to Share Information sub-exception, an actor (such as a health IT developer of certified health IT) who maintains or manages EHI on behalf of another entity (such as a health care provider) 
                        <SU>229</SU>
                        <FTREF/>
                         can rely on the other entity's practice that meets the sub-exception's requirements; the individual need not make a duplicative request for EHI sharing restrictions directly to the actor who is maintaining or managing EHI on behalf of the other entity.) Because the actor met the requirements of that sub-exception, the actor's practice of not providing the requested EHI that cannot be made available due to the individual's request would not constitute information blocking.
                    </P>
                    <FTNT>
                        <P>
                            <SU>229</SU>
                             “Entity” as used in this paragraph could be an individual (such as a licensed health care professional) or an organization (such as a health care facility).
                        </P>
                    </FTNT>
                    <P>
                        • Second, the actor cannot unambiguously segment certain EHI from the EHI that would not be made available due to the individual's request 
                        <PRTPAGE P="1354"/>
                        that the actor has agreed to honor. The Infeasibility Exception is satisfied by a practice that meets a condition in paragraph (a) of § 171.204, such as the 
                        <E T="03">segmentation</E>
                         condition (171.204(a)(2)) and the 
                        <E T="03">responding to requests</E>
                         condition in § 171.204(b). Meeting the § 171.204(b) condition does not require that an actor fulfill any EHI in response to any request but does require that the actor provide the requestor within 10 business days of receipt of the request, in writing, the reason(s) the request is infeasible. Thus, the actor in this example would satisfy the Infeasibility Exception for that portion of EHI that cannot be unambiguously segmented from EHI that cannot be made available due to the individual's request that the actor has agreed to honor. In this example, no other exceptions apply to the EHI that the actor can unambiguously segment from the EHI that cannot be shared because the actor has agreed to the individual's request not to share certain EHI. The actor, therefore, provides the EHI that can be unambiguously segmented and is not subject to the individual's request not to share information in response to the request. If the actor did not provide the EHI that can be unambiguously segmented, then the actor might be engaged in information blocking with respect to the EHI that can be unambiguously segmented.
                    </P>
                    <P>We note that this is only one example to illustrate how the “stacking” of exceptions may occur. We have chosen to detail here an example scenario where an individual has requested restrictions to reinforce actors' and individuals' awareness of the § 171.202(e) sub-exception and to emphasize that the information blocking regulations accommodate actors' choosing to respect an individual's request for restrictions on EHI about the individual. We emphasize, however, that there may be a wide variety of scenarios where “stacking” other combinations of various exceptions with one another, or with restrictions on use or disclosure of EHI under applicable law, may occur.</P>
                    <P>
                        Again, we refer actors and other persons interested in learning more about how the information blocking regulations, and particularly the exceptions, work in concert with the HIPAA Rules and other privacy laws to support health information privacy, to the blog post 
                        <SU>230</SU>
                        <FTREF/>
                         as well as the frequently asked questions referenced and linked above.
                    </P>
                    <FTNT>
                        <P>
                            <SU>230</SU>
                             
                            <E T="03">https://www.healthit.gov/buzz-blog/information-blocking/information-blocking-regulations-work-in-concert-with-hipaa-rules-and-other-privacy-laws-to-support-health-information-privacy</E>
                             (Retrieved 12/07/2023.).
                        </P>
                    </FTNT>
                    <P>We will issue additional guidance as needed and intend to propose additional exceptions in future rulemaking to further support health information privacy, including for information that patients may view as particularly sensitive such as reproductive health-related information.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter expressed concern about the applicability of information blocking regulations where there are data interoperability problems resulting from different implementations of standards by different EHR vendors.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for their input. However, we did not propose information blocking provisions specific to this topic in the HTI-1 Proposed Rule.
                    </P>
                    <HD SOURCE="HD2">B. Defined Terms</HD>
                    <HD SOURCE="HD3">1. Offer Health Information Technology or Offer Health IT</HD>
                    <P>“Health IT developer of certified health IT” is defined for purposes of the information blocking regulations in 45 CFR 171.102. As we discussed in the ONC Cures Act Final Rule (85 FR 25798 through 25799), the definition finalized in that rule includes offerors of certified health IT who do not themselves develop certified health IT or take responsibility for the health IT's certification status under the Program. Specifically, we explained that “an individual or entity that offers certified health IT” would include “any individual or entity that under any arrangement makes certified health IT available for purchase or license” (85 FR 25798, quoted and cited in the HTI-1 Proposed Rule at 88 FR 23857). Both individuals or entities that otherwise fall into at least one category of actor as defined in 45 CFR 171.102—such as health care providers—and individuals or entities that otherwise would not fit the definition of any category of actor could offer certified health IT that they did not themselves develop or present for certification. As offerors of certified health IT, these individuals or entities could engage in conduct that constitutes information blocking as defined in § 171.103, such as through contractual terms or practices undertaken in operating and maintaining health IT deployed by or for another individual or entity.</P>
                    <P>
                        As discussed in the HTI-1 Proposed Rule (88 FR 23858), we proposed to codify in § 171.102 a definition of what it means to 
                        <E T="03">offer</E>
                         certified health IT. As proposed, the definition would provide clarity about the implications under information blocking regulations of making available funding subsidies and certain features or uses of certified health IT as well as engaging in certain other conduct (as discussed in more detail below). Specifically, we proposed to define the term “offer health information technology” or “offer health IT.” For ease of reference, in this preamble, we will generally use the shorter version of the term, “offer health IT” when discussing or referencing the definition. In light of our proposal to establish the “offer health IT” definition, we also proposed (
                        <E T="03">see</E>
                         88 FR 23915 and 88 FR 23864) to update the wording of the “health IT developer of certified health IT” definition specific to the exclusion of certain self-developer health care providers. The proposal specific to the “health IT developer of certified health IT” definition is summarized and discussed in section IV.B.2 below.
                    </P>
                    <P>
                        As explained at 88 FR 23858 through 23859, the definition we proposed for offer health IT generally includes providing, supplying, or holding out for potential provision or supply, certified health IT under any arrangement or terms, but explicitly excludes arrangements and activities specified in paragraphs (1) and (2) of the 
                        <E T="03">offer health IT</E>
                         definition (which are discussed in detail in section IV.B.1.a and b, below). We proposed exclusions of certain arrangements and activities from the offer health IT definition to serve two primary purposes:
                    </P>
                    <P>(1) to encourage certain beneficial arrangements under which providers in need can receive subsidies for the cost of obtaining, maintaining, or upgrading certified health IT; and</P>
                    <P>
                        (2) to give health care providers (and others) who use certified health IT concrete certainty that implementing certain health IT features and functionalities, as well as engaging in certain practices that are common and beneficial in an EHR-enabled healthcare environment, will 
                        <E T="03">not</E>
                         be considered an offering of certified health IT (regardless of who developed that health IT).
                    </P>
                    <P>We also proposed (in paragraph (3) of the offer health IT definition in § 171.102) to exclude from the offer health IT definition the furnishing of certain legal, health IT expert consulting, or management consulting services to health care providers or others who obtain and use health IT. The paragraph (3) consulting and legal services exclusion is discussed in detail in section IV.B.1.c, below.</P>
                    <P>
                        The HTI-1 Proposed Rule included examples illustrating when certain arrangements or activities would or would not fall within a proposed 
                        <PRTPAGE P="1355"/>
                        exclusion (paragraphs (1), (2), and (3)), and clarified that if any individual or entity that engages in some conduct consistent with an exclusion from the offer health IT definition but also engages in other conduct that meets the definition of offer health IT, that individual or entity would be considered a health IT developer of certified health IT. We noted that once an entity meets the definition of health IT developer of certified health IT based on any of its conduct, that definition will apply to all practices of the entity.
                        <SU>231</SU>
                        <FTREF/>
                         (
                        <E T="03">see</E>
                         88 FR 23860 through 23864).
                    </P>
                    <FTNT>
                        <P>
                            <SU>231</SU>
                             Because we are aware that health care provider organizations may be, have, or include one or more physician or other clinicians' professional practices, we note for readers' clarity that unless otherwise specified (such as by being preceded by “clinician” or “office”), we use the word “practice” throughout the section IV of this preamble with the meaning it has in 45 CFR 171.102 (
                            <E T="03">i.e.,</E>
                             “an act or omission by an actor”).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         More than thirty commenters' submissions included comments on the offer health IT definition, health IT developer of certified health IT definition, or both definitions. Of these, over a dozen expressed general support and none expressed general opposition to the proposals.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate all commenters' feedback. We have finalized the proposed offer health IT definition with one revision to the wording to replace “for use by” with “for deployment by or for” other individual(s) and entity(ies). Our response to the comments summarized immediately below explains why we believe this finalized wording change improves clarity of the definition for actors and other interested parties.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         With a reference to the exclusion proposed in paragraph (2) of the offer health IT definition in § 171.102, the Health Information Technology Advisory Committee (HITAC) recommended that we clarify that providing access to registries and similar data services provided by public health authorities is not considered providing health IT, regardless of the route used to request/access/receive data (
                        <E T="03">e.g.,</E>
                         through direct logon to a public health information system, via an app or third-party tool, or via HIN/HIE). The recommendation's rationale was stated as: “This change is necessary to provide users the flexibility to connect to the data resource in the manner of the user's choosing.” Other comments requested that we explicitly exclude, or clarify whether the offer health IT definition excludes, an actor making EHI available through an API or enabling interaction with an API. Commenters also requested clarification on whether such an API-related exclusion would apply to specific types of individuals or entities, or to specific purposes.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Although focused on the detail of the exclusion proposed in paragraph (2) of the offer health IT definition in § 171.102, HITAC's comment informed our review of the interaction between the wording of the proposed offer health IT definition and the distinction between the roles of API User and API Information Source, as we had already defined these roles in § 170.404(c) and (by cross-reference) § 171.102. Specifically, we believe that wording the offer health IT definition in § 171.102 to focus (as proposed, 
                        <E T="03">see</E>
                         88 FR 23915) on holding out or providing or supplying under any arrangement certified health IT “for use by” others may be a source of uncertainty for health care providers, and for others who deploy Certified API Technology in the role of an API Information Source. This uncertainty, we believe, relates to the implications for purposes of the offer health IT definition of a health care provider or other individual or entity in the role of an API Information Source making Certified API Technology available to individuals and entities (other than their own employees and contractors) in the role of API User.
                    </P>
                    <P>
                        At this point, a brief review of the distinction between our definitions of the API User and API Information Source roles, with reference to their establishment in the ONC Cures Act Final Rule (85 FR 25748 through 25749), may help to explain why we now believe clarity is improved by aligning the wording of the offer health IT definition with those two definitions. In the ONC Cures Act Final Rule, we finalized in § 170.404(c) definitions of API User and API Information Source for purposes of the ONC Health IT Certification Program, and by cross-reference to § 170.404(c) adopted those same definitions for purposes of the information blocking regulations in 45 CFR part 171. As discussed in the ONC Cures Act Final Rule at 85 FR 25748 through 25749, we received in response to the ONC Cures Act Proposed Rule (
                        <E T="03">see</E>
                         84 FR 7477 for preamble discussion, 84 FR 7588 for proposed definitions) comments requesting a definition of a “First-Order User” (to include patients, health care providers, and payers that use apps/services) and a definition of a “Third-Party Users” (to include third-party software developers, and developers of software applications used by “API Data Providers”). We decided, as explained in the ONC Cures Act Final Rule (85 FR 25748 through 25749), that such a distinction was unnecessary from a regulatory perspective, and we finalized the API User definition in § 170.404(c) (85 FR 25948) as “a person or entity that creates or uses software applications that interact with the `certified API technology' developed by a `Certified API Developer' and deployed by an `API Information Source.' ” We also defined an API Information Source as an organization that deploys certified API technology created by a Certified API Developer. We noted in the ONC Cures Act Final Rule that the definitions finalized in § 170.404(c) were created to describe relationships and to help describe the Condition and Maintenance of Certification requirements to which developers participating in the ONC Health IT Certification Program are subject (85 FR 25749).
                        <SU>232</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>232</SU>
                             As we clarified in the ONC Cures Act Final Rule (85 FR 25749), health care providers are not subject to the Condition and Maintenance of Certification requirements in § 170.404(c) “unless they are serving the role of a `Certified API Developer.' ”
                        </P>
                    </FTNT>
                    <P>A vast array of interoperable health IT items and services are designed and implemented specifically to achieve increasingly efficient access, exchange, and use of EHI for a wide range of permissible purposes. Thus, in an interoperable health IT ecosystem, one may see third-party apps adopted and used by patients, health care providers, health plans, public health authorities, researchers, and others to achieve access, exchange, or use of EHI by connecting to, interacting with, or otherwise making use of Health IT Module(s) deployed within, for example, a health care provider's EHR system or a public health authority's case reporting infrastructure. Our definition of API User in 45 CFR 170.404(c) illustrates this expectation: it includes both those who create and those who use software applications that interact with API technology deployed by anyone functioning in the role of an API Information Source.</P>
                    <P>
                        We have revised the wording of the finalized offer health IT definition in order to improve certainty for individuals and entities who function in the role of an API Information Source (as defined in § 171.102 by cross-reference to § 170.404(c)) or function in an equivalent role where any APIs involved are not certified but may be part of health IT product(s) that also include one or more Health IT Modules certified under the Program. Specifically, we have replaced in the finalized offer health IT definition the phrase “for use” with the phrase “for 
                        <PRTPAGE P="1356"/>
                        deployment by or for.” We believe this wording is more consistent with the distinction between the act of connecting to, interacting with, or otherwise making use of a health IT item or service (for example, as an API User) and the act of allowing for such connections or interactions with the health IT that an individual or entity (for example, a health care provider) relies on in conducting its own business operations.
                    </P>
                    <P>In addition, we believe this updated wording encompasses the full array of models through which individuals and entities obtain health IT for implementation or other deployment in their operations. We include “or for” in this finalized wording to ensure it is clear that the offer health IT definition is met regardless of whether the customer to whom the health IT is provided or supplied deploys the health IT by themselves or deploys the health IT by having the offeror or any third party(ies) do some or all such implementation and maintenance for them.</P>
                    <P>Providing or supplying health IT that includes one or more Health IT Modules certified under the Program meets the offer health IT definition finalized in § 171.102 regardless of whose employees, contractors, or consultants actually install, configure, manage, or maintain such health IT or other health IT with which such health IT may be integrated, interfaced, or otherwise interact. Likewise, holding out such health IT meets the offer health IT definition regardless of whose employees, contractors, or consultants would be needed, expected, or likely to set it up, manage, or maintain it in the event the holding out of the health IT resulted in the health IT being provided or supplied to one or more other individual(s) or entity(ies). To reinforce this clarity, we note that “deployment by or for” includes, without limitation, all of the following examples in which an individual's or entity's conduct would meet the offer health IT definition (and thus meet the health IT developer of certified health IT definition) in § 171.102:</P>
                    <P>• An individual or entity holds out, or provides or supplies, health IT for deployment by or for potential customer(s) under a software-as-a-service (SaaS) model, infrastructure-as-a-service (IaaS) model, or any combination of these and other model(s) under which the offeror would implement and maintain on behalf of the customer any instance of the health IT. For purposes of this example, it would not matter whether a single-tenant instance would be implemented for each customer or whether one or more customer(s) would share multiple-tenant instance(s) of the health IT with the offeror or other customer(s).</P>
                    <P>• An individual or entity holds out, or provides or supplies, health IT for the customer(s) to implement themselves, using any combination of their own employees and contractors, any single- or multiple-tenant instance(s) of the health IT.</P>
                    <P>• An individual or entity holds out or provides or supplies health IT that is implemented by a third party to customers. For purposes of this example, it would not matter whether a single-tenant instance would be implemented for each customer or whether one or more customer(s) would share multiple-tenant instance(s) of the health IT with the third party or other customer(s).</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested that we provide guidance or examples of how we define “beneficial” and “necessary” in the context of the exclusions from the 
                        <E T="03">offer health IT</E>
                         definition. A commenter requested guidance on our use of the verb “hold out” in the 
                        <E T="03">offer health IT</E>
                         definition. (Comments specific to particular exclusions are addressed in subsections IV.B.1.a through c, below.)
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In the HTI-1 Proposed Rule, we discussed our purposes for proposing the exclusions, including “to encourage beneficial arrangements under which providers in need can receive subsidies for the cost of obtaining, maintaining, or upgrading certified health IT.” Thus, “encourage[ing] beneficial arrangements” explains our intent and rationale for the exclusions (88 FR 23858) and the term “beneficial” does not appear in the text of any of the exclusions. The text of each exclusion defines and describes the arrangements that it excludes from the offer health IT definition.
                    </P>
                    <P>
                        The word “necessary” appeared in the proposed text describing excluded legal services furnished by outside counsel (subparagraph (3)(i) of the § 171.102, offer health IT definition). We did not propose to establish a purpose-specific meaning for the word “necessary” in this context. We intended it to have its widely understood and commonly used meaning of absolutely needed, required, or of an inevitable nature.
                        <SU>233</SU>
                        <FTREF/>
                         Upon review of the comments, we have concluded that we can improve the clarity of subparagraph (3)(i) by deleting the word “necessary.” The updated language uses the phrase “as appropriate to legal discovery” to encompass the activity of facilitating the access or use of the client's health IT when it is necessary as well as when it may be only one of the practicable options through which the counsel's clients can fulfill their legal discovery obligations.
                        <SU>234</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>233</SU>
                             
                            <E T="03">See</E>
                             definitions of the adjective “necessary” by
                        </P>
                        <P>
                            • 
                            <E T="03">Merriam-Webster Dictionary:</E>
                             “1: Absolutely needed: required; 2 a of an inevitable nature” (
                            <E T="03">https://www.merriam-webster.com/dictionary/necessary#:~:text=%3A%20absolutely%20needed%20%3A%20required,of%20an%20inevitable%20nature%20%3A%20inescapable,</E>
                             retrieved Nov 7, 2023);
                        </P>
                        <P>
                            • 
                            <E T="03">Dictionary.com:</E>
                             “1. Essential, indispensable, or requisite. 2. Happening or existing by necessity.” (
                            <E T="03">https://www.dictionary.com/browse/necessary,</E>
                             retrieved Nov 7, 2023).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>234</SU>
                             The offer health IT definition exclusion in subparagraph (3)(i) encompasses the activities by counsel it describes for both EHI and other electronically stored information (ESI). For purposes of legal discovery, ESI includes writings, drawings, graphs, charts, photographs, sound recordings, images, or other data or data compilations. (
                            <E T="03">See, e.g.,</E>
                             Fed. R. Civ. P. 34(a)(1)(A).).
                        </P>
                    </FTNT>
                    <P>
                        We use the term “hold out” in the text of the offer health IT definition as a transitive verb. As such, we believe “hold out” is generally understood in common usage to mean presenting an item or service as something realizable, attainable, or for acceptance.
                        <SU>235</SU>
                        <FTREF/>
                         With his common usage in mind, we use “hold out” to ensure it is clear that an individual or entity's activities can meet the definition of offer health IT without anyone accepting the proffer of a sale (or resale) or of a license (or relicense), and without anyone otherwise obtaining or using any Health IT Module(s) from that individual or entity. This operates as a safeguard against, for example, the holding out for sale or license one or more ONC-certified Health IT Module(s) (or products containing such Module(s)) and ultimately only agreeing to provide non-certified health IT in an attempt to avoid meeting the 
                        <E T="03">offer health IT</E>
                         definition and to avoid being subject to information blocking regulations. For purposes of the information blocking regulations, if any individual or entity is holding out health IT that includes one or more ONC-certified Health IT Modules, that individual or entity will be considered to be offering health IT and thus would meet the definition of health IT developer of certified health IT.
                    </P>
                    <FTNT>
                        <P>
                            <SU>235</SU>
                             
                            <E T="03">See e.g., https://www.merriam-webster.com/dictionary/hold%20out</E>
                             (Retrieved Jul 6, 2023): “to present something as realizable: proffer.”
                        </P>
                    </FTNT>
                    <P>We further note that whether such a scenario might implicate other federal or state laws does not affect whether an individual or entity's conduct meets the offer health IT definition.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter requested we ensure adequate protection of the 
                        <PRTPAGE P="1357"/>
                        provision of open-source tools developed by open-source communities, irrespective of the terms on which they are made available, whether the tool is necessary for use of the product or the provision of care or whether the tool is integrated into a certified health IT product as part of the product. This comment appears to convey uncertainty on the commenter's part about whether a health care provider's (for example, a health system) integration of open-source modules with the certified health IT products it deploys (or has deployed by a third party on its behalf) to support its provision of patient care and other operational activities meets the offer health IT definition. The commenter also encouraged ONC to ensure that the provision of clinical decision support modules by a health system through an open-source community is protected. This comment also appears to convey uncertainty on the commenter's part as to if or when a participant in an open-source community might be considered to offer health IT and, therefore, would meet the health IT developer of certified health IT definition in § 171.102.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We will discuss here how the finalized definition addresses these concerns, in the order in which they are summarized above.
                    </P>
                    <P>
                        First, specific to a health care provider deploying open-source health IT to support its provision of patient care and other operational activities, we do not believe that the fact that the health care provider is deploying open-source health IT impacts the analysis. As we discussed above, the offer health IT definition as finalized aligns with the API User and API Information Source role definitions previously established in § 171.102 and we believe the finalized definition of offer health IT provides clarity that deploying 
                        <SU>236</SU>
                        <FTREF/>
                         health IT that incorporates one or more Health IT Modules certified under the Program is not an activity that meets the offer health IT definition, regardless of whether, or how much of, the health IT in question was developed by an open-source community or any other source or developer of health IT. For purposes of the finalized offer health IT definition, we do not treat deploying a health IT product developed by an open-source community different from deploying a health IT product developed by a commercial developer.
                    </P>
                    <FTNT>
                        <P>
                            <SU>236</SU>
                             As discussed above, the individual or entity “deploying” the health IT need not, for purposes of the offer health IT definition, do any or all of the implementation or maintenance of the health IT. The deploying individual or entity could have any or all implementation and maintenance work for the health IT done for them by the offeror or one or more third party(ies).
                        </P>
                    </FTNT>
                    <P>
                        Also of note, the finalized offer health IT definition focuses on the holding out or provision or supply of certified health IT products for deployment by or for other individual(s) or entity(ies). As cited in the HTI-1 Proposed Rule in connection to the proposed implementation and use activities exclusion (paragraph (2) of the offer health IT definition (88 FR 23860)), we noted in the ONC Cures Act Final Rule that “some use of a self-developer's health IT may be made accessible to individuals or entities 
                        <E T="03">other than</E>
                         the self-developer and 
                        <E T="03">its employees</E>
                         without that availability being interpreted as offering or supplying the health IT 
                        <E T="03">to other entities</E>
                         in a manner inconsistent with the concept of `self-developer' ” (85 FR 25799, emphasis added). We add emphasis here to “other than . . . its employees” and “to other entities” to highlight that the offer health IT definition is not met by an individual or entity deploying health IT for use or implementation in their own operations by their employees and contractors in the course of employment or scope of the contract. We further note that the offer health IT definition is not met when the action is deployment that makes the health IT available to individuals in certain non-employee roles other than the deploying entity's contractors. For these reasons, a health care provider deploying health IT in the health care provider's own operations would not meet the offer health IT definition—whether the health IT is open-source or not.
                    </P>
                    <P>Turning to the question of participation in an open-source development effort, we believe the question of which participants in such communities fall within the definition of offer health IT is, necessarily, dependent on the specific facts and circumstances of any given case. For example, relevant facts would include which participants in an open-source community have undertaken what role(s) and responsibility(ies) in relation to the certification status of the Health IT Module(s) involved.</P>
                    <P>The question of whether or when a participant in an open-source community engages in conduct that constitutes holding out, or providing or supplying, health IT that includes at least one certified Health IT Module is similarly, and also necessarily, dependent on the specific facts and circumstances of the conduct. In any case, it is also important to recall that the offer health IT definition that we proposed, and have finalized, cannot be met unless the technology held out, or provided or supplied, for deployment by or for others includes one or more Health IT Module(s) certified under the Program. To the extent an open-source community produces only non-certified health IT items or services, the development or offering of that non-certified health IT would not, of itself, result in the community or its participants being considered health IT developers of certified health IT—regardless of whether the product is intended, designed, or fit for use only in conjunction with certified health IT in general or specific certified health IT product(s). The community's exclusively non-certified health IT items or services may be styled, branded, named by the community, or commonly referenced in the marketplace as products, apps, modules, or something else without affecting whether the community's conduct falls within the § 171.102 offer health IT definition. Neither the holding out nor the providing or supplying of entirely and exclusively non-certified health IT can meet the offer health IT definition.</P>
                    <P>
                        We recognize that once integrated with any deployment of a compatible certified product (such as ONC-certified EHR software), a non-certified health IT item such as a macro or template might be difficult or impossible for the end user (such as a doctor using a health system's EHR system to document a diagnosis) to distinguish from the certified health IT product. For individuals or entities who deploy certified health IT product(s), we recognize that sharing such items with others may raise questions similar to the one posed by the comment specific to open-source health IT: does sharing with other individuals or entities a non-certified item that, as experienced by end users, may seem like part of a certified health IT product meet the offer health IT definition? 
                        <SU>237</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>237</SU>
                             For ease of reference, we may sometimes refer to suites, bundles, or other combinations of health IT items, services, or functions that include one or more Health IT Modules certified under the Program as “certified health IT products.”
                        </P>
                    </FTNT>
                    <P>
                        We note that whether an actor's conduct meets the offer health IT definition is 
                        <E T="03">not</E>
                         determined by the end user's perception of what is or is not part of a single certified health IT product. Likewise, whether an individual's or entity's conduct meets the offer health IT definition is not determined by whether a particular health IT item or service that is not 
                        <E T="03">certified</E>
                         health IT can or cannot be used independently of certified health IT. The individual's or entity's conduct can meet the offer health IT definition only when the health IT that the individual 
                        <PRTPAGE P="1358"/>
                        or entity holds out, or provides or supplies, includes at least one Health IT Module certified under the ONC Health IT Certification Program.
                    </P>
                    <P>
                        Even if a non-certified health IT item or service (for example, a macro or template) can only be used in conjunction with a specific certified health IT product, the offer health IT definition is not met by holding out, or by providing or supplying, for deployment by or for others 
                        <E T="03">only</E>
                         the non-certified health IT item or service. For example, a health care provider might choose to make available to other members of a developer's user group a macro that works only with one of the developer's Health IT Modules that is certified to § 171.315(b)(3). The hypothetical macro in this example is not a Health IT Module that is certified under the Program, and does not include any Health IT Module(s) certified under the Program when the health care provider makes it available to other members of the user group. In this example scenario, the act of supplying the non-certified macro to other individual(s) or entity(ies) does not meet the definition of offer health IT.
                    </P>
                    <P>For a similar example, an open-source community or its participants could make available a “clinical decision support” (CDS) algorithm. In this example, the CDS algorithm is not a Health IT Module that is certified under the Program. The act of holding out the algorithm for deployment by or for others does not meet the offer health IT definition because the algorithm is not certified health IT. Likewise, the act of providing or supplying the algorithm for deployment by others does not meet the offer health IT definition. If, however, the algorithm was included as a part of a certified health IT product, and an individual or entity holds out, or provides or supplies, the certified health IT with the algorithm in it for deployment by other individual(s) or entity(ies), that conduct would meet the offer health IT definition.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Two comments on the offer health IT definition referenced reporting requirements in connection to the offer health IT definition. These comments did not identify specific reporting requirements they perceived entities would become subject to by engaging in conduct meeting the offer health IT definition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As established by the ONC Cures Act Final Rule and updated by the provisions finalized in this rule, the information blocking regulations (45 CFR part 171) do not include any requirements for any actor to proactively report to ONC.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters suggested that hosting, the provision of hosting services, or “extending their EHR” by health care providers for other health care providers should be excluded from the definition of offer health IT. One such commenter stated a view that such organizations should not be considered to offer health IT and should not be subject to “more stringent” information blocking requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In the HTI-1 Proposed Rule, we did not propose defining what conduct would meet or not meet the offer health IT definition based on whether it was done by an individual or entity that otherwise meets the definition of any type of actor (as the term actor is defined in § 171.102). These commenters' rationale for excluding hosting, the provision of hosting services, or “extending their EHR” by health care providers for other health care providers centered on preventing health care providers engaged in such conduct from also meeting the definition of health IT developer of certified health IT. Therefore, we discuss in context of our proposal to update the health IT developer of certified health IT definition (
                        <E T="03">see</E>
                         section IV.B.2 of this preamble, below) why we decline to establish at this time any regulatory provision with the effect these comments advocate.
                    </P>
                    <P>
                        <E T="03">Summary of finalized policy—offer health IT:</E>
                         we have finalized the proposed offer health information technology or offer health IT definition with a revision to its wording in response to comments received. The wording revision is from “for use by other individual(s) or entity(ies)” to “for deployment by or for other individual(s) or entity(ies).”
                    </P>
                    <P>To increase clarity, we have further revised the definition by replacing the phrase “under any arrangement other than the following” with “under any arrangement except an arrangement consistent with subparagraph (3)(iii), below.” As discussed above, activities described in other paragraphs and subparagraphs we do not interpret as holding out or as providing or supplying health IT for deployment by or for other individuals or entities. Thus, only subparagraph (3)(iii) functions to exclude from the offer health IT definition arrangements under which someone obtains from an individual or entity any certified Health IT Module(s).</P>
                    <P>To improve readability, we also revised the opening phrases of the definition. This revision was from “. . . means to hold out for sale, resale, license, or relicense; or to sell, resell, license, relicense, or otherwise provide or supply health information technology (as that term is defined in 42 U.S.C. 300jj(5)) that includes one or more Health IT Modules certified under the ONC Health IT Certification Program, . . .” to “. . . means: to hold out for sale, resale, license, or relicense; or to sell, resell, license, relicense, or otherwise provide or supply health information technology (as that term is defined in 42 U.S.C. 300jj(5) and where such health information technology includes one or more Health IT Modules certified under the ONC Health IT Certification Program) . . .” as finalized.</P>
                    <P>For readability, we added a second sentence to the offer health IT definition that also enhances clarity as to the function of the definition's subparagraphs on the whole. That added sentence reads: “Activities and arrangements described in subparagraphs (1) through (3) are considered to be excluded from what it means to offer health IT.”</P>
                    <P>The finalized definition is shown in its entirety in the CFR amendatory instructions for § 171.102 (see “Regulation Text” section of this rule, below).</P>
                    <HD SOURCE="HD3">a. Exclusion of Certain Funding Subsidy Arrangements From Offer Health IT Definition</HD>
                    <P>In the HTI-1 Proposed Rule, we included a provision to address concerns regarding the potential of some health care providers and other donors to stop making available funding subsidies that would go toward the cost of certified health IT in situations where the receiving health care provider is not able to afford the cost of the certified health IT. The proposal, in paragraph (1) of the offer health IT definition in § 171.102, explicitly excluded certain arrangements that focused on providing funding subsidies for providers to obtain, maintain, and/or upgrade certified health IT. We explained how this exclusion would operate in the HTI-1 Proposed Rule (88 FR 23859). We refer readers to the HTI-1 Proposed Rule for the full discussion of the donation and subsidized supply arrangements exclusion (paragraph (1)).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Of the comment submissions addressing this proposed exclusion, six supported exclusion of funding subsidy arrangements from the offer health IT definition. One comment submission did not express general opposition to the exclusion but expressed opposition to the definition of offer health IT excluding subsidies tied to a specific product, or excluding subsidies that would promote or 
                        <PRTPAGE P="1359"/>
                        prioritize imaging referrals of patients to the subsidizing entity or its partners. This comment, from two large clinical societies, recommended that if we finalize this exclusion, we state in preamble that promotion or prioritization of the subsidizing entity's services over those of unaffiliated, competing providers would not be exempted from the offer health IT definition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' feedback. We have finalized the exclusion of funding subsidy arrangements (paragraph (1) of the offer health IT in § 171.102) as proposed (88 FR 23915). The donation and subsidized supply arrangements exclusion as proposed and as finalized is conditional, as indicated by this language in paragraph (1) of the offer health IT definition: “provided such individual or entity offers and makes such subsidy without condition(s) limiting the interoperability or use of the technology to access, exchange, or use electronic health information for any lawful purpose.” Thus, the donation and subsidized supply arrangements exclusion (paragraph (1)) does 
                        <E T="03">not</E>
                         apply if the subsidy is conditioned on limiting the interoperability or use of the technology to access, exchange, or use EHI for any lawful purpose. Any agreement terms, statements (written or oral), patterns of conduct, or singular actions whereby the source of donation or funding subsidy conditions the donation on the recipient's limiting its use of health IT or its access, use, or exchange of EHI in ways specified or signaled by the funding source would be considered a condition limiting interoperability or use of the technology. Therefore, we do not believe that the purpose of this exclusion would be better served by limiting it at this time to arrangements under which recipients can choose to apply a funding subsidy to a minimum array of products or to any product on the market. However, we plan to remain alert for signals that funding subsidy sources may be misusing this exclusion.
                        <SU>238</SU>
                        <FTREF/>
                         We note that we may consider amending this definition in future rulemaking in response to changing market conditions.
                    </P>
                    <FTNT>
                        <P>
                            <SU>238</SU>
                             Patterns described to us in claims or suggestions of possible information blocking submitted through the Report Information Blocking Portal represent just one example of the ways such signals may come to our attention. (The Report Information Blocking Portal's URL is: 
                            <E T="03">https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/6</E>
                            ). Information on the claims process that is publicly available on Health IT.gov (
                            <E T="03">https://www.healthit.gov/topic/information-blocking</E>
                            ) includes a fact sheet on the Report Information Blocking portal process (
                            <E T="03">https://www.healthit.gov/sites/default/files/page2/2021-11/Information-Blocking-Portal-Process.pdf</E>
                            ) and a resource titled “Information Blocking Claims: By the Numbers” (
                            <E T="03">https://www.healthit.gov/data/quickstats/information-blocking-claims-numbers</E>
                            ). As of October 2023, “Information Blocking Claims: By the Numbers” provides the total number of portal submissions received since April 5, 2021, the number of these submissions that represent claims of possible information blocking, and the number of these claims by type of potential actor and type of claimant. (URLs confirmed Oct 18, 2023.)
                        </P>
                    </FTNT>
                    <P>We appreciate commenters' concerns about donation or subsidy arrangements tied to specific technology where the donation or arrangement is for the purpose of promoting referrals to the source of the funding or its affiliates. We believe the proviso in the donation and subsidized supply arrangements exclusion (paragraph (1)), as proposed, is sufficient to ensure it does not apply to arrangements conditioned by the source(s), donor(s), or giver(s) on limiting interoperability or use of the technology. As stated in the HTI-1 Proposed Rule, we do not believe it is necessary to assess, for purposes of determining whether a funding subsidy should be considered an offer of certified health IT, whether the source(s) of the subsidy conditions the subsidy on the recipient referring patients to or away from the source. As we noted, there may be other laws implicated by solicitation or receipt of any remuneration in return for referral steering and similar conduct (88 FR 23859). For example, the Federal Anti-Kickback Statute (42 U.S.C. 1320a-7b(b), section 1128B(b) of the Social Security Act) could be implicated where remuneration is directly or indirectly offered, paid, solicited, or received for the referral of or arrangement of a referral of any item, service, or good for which payment may be made in whole or part under a “Federal health care program” (as defined in 42 U.S.C. 1320a-7b(f)). Nothing in this final rule should be construed as creating an exception to any fraud and abuse laws.</P>
                    <P>In light of the commenters' concern, we believe it may be useful to clarify how the donation and subsidized supply arrangements exclusion from the offer health IT definition operates for purposes of 45 CFR part 171 in the context of a donor or funding source that is using a subsidy to steer referrals or to distort the market for healthcare items or services through a condition(s) that limit the use of donation-supported or subsidized technology or the lawful access, exchange, or use of EHI. As noted in the HTI-1 Proposed Rule (at 88 FR 23859), we interpret “conditions limiting the interoperability or use of the technology to access, exchange, or use electronic health information” broadly. Specifically, we noted we would consider conditions to include not only the explicit terms of any written agreement but also oral statements and patterns of conduct on the part of the subsidy's source(s) toward, in the presence of, or made known by the source(s) to the subsidy's recipient. We further noted that we would consider a condition(s) to include a subsidy source limiting the use of the subsidy to particular technology that includes, or otherwise arranges for subsidy-supported technology to include, features, functions, coding, or other means that would limit recipients' options to lawfully use that technology to access, exchange, or use EHI. A recipient health care provider's access, exchange, and use of EHI for such purposes is not limited to but necessarily includes access, exchange, and use by care team members in the course of making diagnosis and treatment decisions within their scopes of practice and making referrals in accord with their professional judgement and understanding of their patient's preferences.</P>
                    <P>
                        The limitation on the application of the offer health IT definition's donation and subsidized supply arrangements exclusion in paragraph (1) of the definition is, as noted in the HTI-1 Proposed Rule, a safeguard against inappropriate use of the exclusion by entities seeking to distort the health IT market. This would include efforts to limit recipients' options to use additional technology or to otherwise impede innovations and advancements in health information access, exchange, and use (88 FR 23859). The donation and subsidized supply arrangements exclusion (paragraph (1)) applies only where the individual or entity donates, gives, or otherwise makes available funding 
                        <E T="03">without</E>
                         condition(s) limiting the interoperability or use of the technology to access, exchange, or use EHI for any lawful purpose. We did not propose that the exclusion could apply to any arrangement conditioned in any way on limiting the interoperability or use of the subsidy-supported technology or the recipient's use of the technology to access, exchange, or use EHI for any lawful purpose. We have finalized the exclusion as proposed.
                    </P>
                    <P>
                        We further clarify in view of comments received that the limitation on application of the donation and subsidized supply arrangements exclusion in paragraph (1) of the definition does not consider what underlying intent or motive the funding source may have for any condition that limit the interoperability or use of the 
                        <PRTPAGE P="1360"/>
                        technology to access, exchange, or use electronic health information for any lawful purpose. Any condition that has such effect will mean the arrangement falls outside of the donation and subsidized supply arrangements exclusion (paragraph (1) of the offer health IT definition). Then, whether such non-excluded funding subsidy or donation arrangements would constitute the funding source offering health IT would have to be evaluated to determine whether the conduct constitutes holding out for sale, resale, license, relicense, or otherwise providing or supplying health information technology for deployment by other individual(s) or entity(ies).
                    </P>
                    <P>
                        To note, any third-party health IT developer of certified health IT or HIN/HIE that may be engaged in funding subsidy arrangements related to providing, configuring, or otherwise supporting health IT will want to bear in mind that their engagement in any practice they know or should know is likely to 
                        <E T="03">interfere with</E>
                         access, exchange, or use of EHI could constitute information blocking on the part of the actor (unless an applicable law requires or an exception set forth in 45 CFR part 171 is satisfied by such practice). This includes scenarios where the practice occurred at the direction of or on behalf of a funding subsidy source. This would be true for the health IT developer of certified health IT or an HIN/HIE regardless of whether the funding subsidy source or recipient is also an actor, and regardless of whether the funding subsidy source or recipient also engaged in conduct meeting the information blocking definition.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters recommended we adopt a policy under which a health care provider would not be considered to offer health IT, or be considered only a health care provider and excluded from the “health IT developer of certified health IT” definition, even if they “extend their EHRs” or otherwise donate or provide health IT on terms more affordable to a recipient than those available from other vendors of health IT items or services. Several commenters suggested such provision of health IT be excluded from the definition of offer health IT. A commenter that is a health system advocated for an explicit exclusion in situations where a health care provider hosts instances of a particular developer's EHR for other health care providers. A developer of certified health IT advocated to exclude from the definition of offer health IT any health IT resale or relicensing arrangements on non-discriminatory bases between health care providers or HIPAA covered entities. The developer's comment acknowledged the potential for organizations hosting or otherwise reselling health IT to make configurations or other implementation decisions potentially implicating the information blocking definition but asserted they had not observed this to have occurred among the providers reselling the developer's health IT.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' sharing their experiences and perspectives. We did not propose that the donation and subsidized supply arrangements exclusion from the offer health IT definition would apply to a health care provider selling, licensing, or otherwise providing or supplying certified health IT (whether such health IT is self-developed by the provider offering it or obtained from a third-party developer) to other health care providers on a subsidized, discounted, or other basis. We decline to do so for reasons we discuss in this response and in Section IV.B.2 of this preamble below.
                    </P>
                    <P>We cannot be certain whether commenters' reference to providers who “extend their EHRs” or similar wordings are meant to describe the donor health care provider entity selling, reselling, licensing, relicensing, or otherwise providing or supplying the health IT itself for deployment by the recipient providers. Therefore, to ensure clarity, we note that we perceive a clear distinction between two kinds of conduct. One distinct kind of conduct is donating, giving, or otherwise making available to a recipient funding to cover costs of an item or service (such as health IT that includes one or more Health IT Modules certified under the Program). A distinctly separate kind of conduct is the sale, resale, licensing, relicensing, or otherwise providing or supplying of the item or service itself to the recipient.</P>
                    <P>
                        We proposed that the donation and subsidized supply arrangements exclusion (paragraph (1)) to encompass arrangements where “an individual or entity donates, gives, or otherwise makes available funding to subsidize or fully cover the costs of a health care provider's acquisition, augmentation, or upkeep of health IT” (88 FR 23915). We stated in the HTI-1 Proposed Rule that the proposed donation and subsidized supply arrangements exclusion “would remove from the definition of 
                        <E T="03">offer health information technology</E>
                         or 
                        <E T="03">offer health IT</E>
                         the provision of subsidies, in the form of funding or cost coverage subsidy arrangements for certified health IT” (88 FR 23859). We have finalized the donation and subsidized supply arrangements exclusion (paragraph (1)) of the offer health IT definition (§ 171.102) as proposed. Thus, the finalized first exclusion of the definition encompasses furnishing monetary resources (as described at 88 FR 23859, “subsidies, in the form of funding or cost coverage subsidy arrangements”) for an item or service.
                    </P>
                    <P>
                        We reiterate that the donation and subsidized supply arrangements exclusion as proposed and as finalized in paragraph (1) of the offer health IT definition does 
                        <E T="03">not</E>
                         encompass any arrangement where an individual or entity does any of the following to or with any health IT that includes one or more certified Health IT Module(s):
                    </P>
                    <P>• holds out the health IT for sale, resale, license, or relicense for deployment by or for other individual(s) or entity(ies);</P>
                    <P>• sells, resells, licenses, relicenses the health IT for deployment by or for other individual(s) or entity(ies); or</P>
                    <P>• otherwise provides or supplies the health IT for deployment by or for other individual(s) or entity(ies).</P>
                    <P>To prevent any potential confusion or misunderstanding about the significance of our reference to “subsidized supply” arrangements in the text of the exclusion in (paragraph (1) of the offer health IT definition, we note that this is included to explicitly recognize a type of arrangement whereby a donor or other subsidy source subsidizes or fully covers costs by payment of such costs to the individual or entity that develops or offers the health IT item(s) or service(s) subsidized.</P>
                    <P>
                        For an example of a scenario in which the donation and subsidized supply arrangements exclusion (paragraph 1) applies: a health system arranges with a health IT developer that the health system will pay eighty-five percent of the cost of any contract for use of a (developer hosted) EHR product suite by any health care provider that gives the developer a particular code that was supplied to the health care provider by the health system. Note that in this example the EHR product suite includes one or more Health IT Modules certified under the Program (because the offer health IT definition is not met if health IT that is held out or that is provided or supplied does not include any such Health IT Module(s).) The health system gives the code to independent safety net providers in its service area as a means of making funding available to the safety net providers to cover part of the safety net providers' cost to obtain and maintain use of an EHR product suite. A critical part of an analysis of the application of the exclusion in this example is whether money covering (part of) the contract costs for health IT 
                        <PRTPAGE P="1361"/>
                        is being supplied or whether the health IT itself is being supplied by the health system. Here the health system is only making a funding subsidy available. The health IT developer is supplying the health IT (EHR product suite).
                    </P>
                    <P>In a different example, where a health system instead offers to host and support ONC-certified health IT for a safety net provider, the health system would be engaged in conduct to which the donation and subsidized supply arrangements exclusion (paragraph (1)) would not apply. Regardless of whether the entity doing the holding out or furnishing of health IT (or anyone else) would be subsidizing (in whole or in part) the costs of the health IT, the donation and subsidized supply arrangements exclusion (paragraph (1)) does not apply where an individual or entity holds out or, under any arrangement, provides or supplies for deployment by or for other individual(s) or entity(ies) any health IT product(s) that include one or more Health IT Modules certified under the Program.</P>
                    <P>We recognize that some health care providers, or other individuals or entities, may choose to engage, on a subsidized basis for the recipient or as a donation to the recipient, in conduct that is not encompassed by the exclusion in paragraph (1) but to which another exclusion to the offer health IT definition applies. In the interest of providing such individuals and entities certainty, we note that if any exclusion to the offer health IT definition applies to any particular conduct, it does not matter whether one or more other exclusion(s) do or do not also apply. If at least one exclusion applies to any particular conduct, that conduct is excluded from the offer health IT definition.</P>
                    <P>Finally, we note again that donation and subsidized supply arrangements can implicate other laws, including the Federal Anti-Kickback Statute and nothing in this final rule should be construed as creating an exception to any fraud and abuse laws.</P>
                    <P>We further discuss below, in the context of the health IT developer of certified health IT definition (section IV.B.2), our current position regarding health care providers who choose to engage in conduct that meets the offer health IT definition. However, it is important for providers and other individual(s) or entity(ies) interested in engaging in any conduct that meets the offer health IT definition to note that engaging in such conduct makes the individual or entity one that offers health IT. This means such an individual or entity will meet the health IT developer of certified health IT definition regardless of whether the individual or entity also happens to engage in any other conduct that is encompassed by an exclusion from the definition or that otherwise does not meet the offer health IT definition.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter requested we confirm that subsidy arrangements where the funding source is not otherwise a § 171.102 actor are encompassed by the exclusion. The comment cited, as an example, subsidies from health plans to providers. Another comment recommended that we clarify the offer health IT definition excludes subsidy arrangements between healthcare entities, such as a health plan and community provider. Other comments suggested that we should reiterate that engaging in activities described in exclusion (1) is not a way for an individual or entity that is otherwise a § 171.102 actor to opt out of being subject to information blocking regulations.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The finalized donation and subsidized supply arrangements exclusion (paragraph (1)) applies to the arrangements it describes. It does not specify characteristics that the source of the subsidy must have (or not have) for the arrangement to be excluded from the offer health IT definition. If any person engages in conduct described in paragraph (1), that means the excluded conduct does not fall within the definition of offer health IT. Thus, engaging in conduct described in paragraph (1) of the offer health IT definition will not turn an individual or entity who does not otherwise meet the § 171.102 actor definition into an “actor” for purposes of the information blocking regulations.
                    </P>
                    <P>It is important to remember, however, that engaging in conduct described in the donation and subsidized supply arrangements exclusion (paragraph 1) simply has no effect on whether a person is not or is considered an actor as defined in § 171.102 for purposes of 45 CFR part 171. Even if an individual or entity that is otherwise an actor engages in conduct described in subparagraph (1) of the offer health IT definition, the person is still an actor. For example, if any entity meets the § 171.102 definition of health care provider then that entity is a health care provider regardless of whether it also happens to engage in conduct described in the donation and subsidized supply arrangements exclusion from the offer health IT definition. Also, any entity meeting the § 171.102 definition of health IT developer of certified health IT through any of its activities is a health IT developer of certified health IT regardless of whether it also happens to engage in conduct described in the donation and subsidized supply arrangements exclusion (paragraph 1).</P>
                    <P>
                        A health care provider or health IT developer of certified health IT would remain subject to the information blocking regulations for any of their conduct that meets the definition of information blocking in § 171.103, including when that conduct occurs in the course of activities that fit the description of any exclusion from the offer health IT definition. Similarly, when and to the extent a health plan, health plan issuer, or any other entity engages in conduct meeting the functional definition of health information network or health information exchange (HIN/HIE), then that entity is a HIN/HIE regardless of whether the entity also happens to engage, at the same time, in conduct described in any exclusion from the offer health IT definition.
                        <SU>239</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>239</SU>
                             The 
                            <E T="03">health information network</E>
                             or 
                            <E T="03">health information exchange</E>
                             definition is a functional definition. 
                            <E T="03">See</E>
                             45 CFR 171.102, 
                            <E T="03">see also</E>
                             85 FR 25800 through 85 FR 25803.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter who referenced experience with donation of hospital equipment noted it is important for recipients of donated technology to have access to design documents, data schema, and other resources needed to facilitate the use of donated health IT systems through maintenance, process improvement, and interoperability concerns. This commenter encouraged ONC to provide a broad dissemination of publicly available user manuals, access to spare parts, and consumable resources to facilitate the use of donated equipment. A commenter suggested we consider adjusting conditions of the donation and subsidized supply arrangements exclusion to address the impact of discontinued subsidies on the recipient's ability to maintain the health IT over time.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the concerns raised by these comments. Specific to Health IT Modules certified under the ONC Health IT Certification Program, our Program regulations in 45 CFR part 170 provide for public availability of certain information and documentation about the technology. (
                        <E T="03">See</E>
                         45 CFR 170.523 disclosures applicable to certified Health IT Modules, 45 CFR 170.404(a)(2) transparency conditions for Certified API Technology.) To the extent documentation needed to effectively use health IT products that include non-certified items and services in complement to one or more Health IT Module(s) certified under the Program, such documentation would fall outside 
                        <PRTPAGE P="1362"/>
                        the scope of the Program's disclosures and transparency requirements. However, we believe the information blocking regulations discourage an actor from inappropriately withholding access to such documentation from recipients of their health IT. If an actor's practice of denying the recipients of health IT such information is likely to interfere with access, exchange, or use of EHI, that practice could implicate the information blocking definition. It is not clear what consumable supplies or spare parts relevant to health IT were referenced by the comment advocating ONC provide broad access to them. It is also not clear what is meant by the commenter advocating ONC “provide access” to spare parts and consumables. We note that the information blocking regulations maintain policies supportive of the access, exchange, and use of EHI and include policies under which the individuals and entities who actually supply health IT (donated or otherwise) for deployment by or for other individuals or entities generally continue to be subject to enforcement under the information blocking regulations as health IT developers of certified health IT.
                    </P>
                    <P>Concerns specific to a supplier of technology withholding access to documentation and resources needed to use systems represents one example of conduct likely to interfere with a recipient's access, exchange, or use of EHI. This concern illustrates just one of many possible practices any individual or entity that engages in conduct meeting the finalized offer health IT definition would have opportunity to engage in that would be likely to interfere with customers' and others' ability to access, exchange, or use EHI in or through the health IT “offered.” Such opportunities to interfere with customers' access, exchange, or use of EHI are among the reasons we believe it would be inappropriate to exclude from the offer health IT definition the sale, resale, licensing, or relicensing of any Health IT Module based on such offering being subsidized by the offeror or a third party. Therefore, such conduct will generally continue to fall within the offer health IT definition. By engaging in any conduct falling within the offer health IT definition, the individual or entity engaged in the conduct meets the health IT developer of certified health IT definition and is subject to information blocking regulations accordingly.</P>
                    <P>We further note that this comment highlights the importance of prospective recipients of technology donations carefully considering the full terms of both the donation or subsidy arrangement and any contracts or other agreements with a developer, seller, reseller, licenser, or relicenser of the technology involved. For example, and for practical reasons entirely independent of the information blocking regulations, it is important for a recipient to know what items and services are included in the subsidy or donation and the level, extent, and duration of support for those items or services that the donation commits the funding source to cover. The information blocking regulations do not eliminate the need for anyone contemplating adopting health IT items or services pursuant to a donation or subsidy arrangement to consider and plan for their ability to maintain the health IT in good working order, or successfully transition away from it, at the end of a one-time donation or subsidy arrangement or in the event an arrangement providing an ongoing subsidy were to be discontinued (or not renewed). This would be true for adoption of initial, additional, upgraded, or replacement health IT items or services.</P>
                    <P>We also note that whether, as potential recipients of subsidized health IT or as a customer paying the full cost or market price themselves, all prospective recipients of any health IT will likely find it important to know and understand the terms of all agreements with the developer or offeror of health IT items or services they obtain. For example, a customer contemplating adoption of any health IT item or service would want to consider the potential that they may want to replace that particular product with another product in the future. Such a customer would want to look closely at how any data the product stores will be returned to the customer at the end of the agreement with the developer or other offeror of the health IT, and what support may be available, and on what terms, to help the customer (or a health IT developer or support contractor of the customer) import the data into the next product the customer will use to access, exchange, or use that data.</P>
                    <P>
                        Recipients of donated health IT, like all customers of health IT, will also find it important to know whether technology they are considering for adoption includes any Health IT Module(s), or if the developer or offeror that would provide the technology has any Health IT Module(s), certified under the Program. An individual or entity that develops or offers health IT, but who does not develop or offer any certified Health IT, might not be subject to information blocking regulations unless the individual or entity is a health care provider or a HIN/HIE as defined in § 171.102.
                        <SU>240</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>240</SU>
                             The § 171.102 health care provider and HIN/HIE definitions do not have a definitional component related to certified health IT. An individual or entity can meet either or both of these definitions without having, using, or offering any certified health IT.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Summary of finalized policy—donation and subsidized supply arrangements exclusion (paragraph 1):</E>
                         After consideration of the comments received that are relevant to, and within the scope of, this proposal, we finalized the policy, as proposed. Provision of funding to a recipient who will use it to cover some or all of the recipient's health IT acquisition, augmentation, or upkeep cost is explicitly excluded from the offer health IT definition. Likewise, arrangements whereby a funding source (whether or not referenced or styled as a “donor”) pays, remits, or otherwise transfers to a third-party funds covering the cost (in whole or part) of a health care provider's acquisition, augmentation, or upkeep of health IT are explicitly excluded from the offer health IT definition to the extent they are consistent with paragraph (1). However, the text of paragraph (1) explicitly and intentionally limits application of the donation and subsidized supply arrangements exclusion to those arrangements whereby the source of the subsidy makes available funding to cover costs of acquisition, augmentation, or upkeep of health IT. The finalized paragraph (1), donation and subsidized supply arrangements exclusion from the offer health IT definition, does 
                        <E T="03">not</E>
                         apply to sale, licensing, resale, relicensing, or provision or supply of the health IT itself—regardless of whether such provision or supply is on subsidized or other terms.
                    </P>
                    <P>We reiterate that no individual or entity that otherwise meets the definition of any type of actor in § 171.102 can opt out of being subject to information blocking regulations by engaging in any activity excluded from the offer health IT definition.</P>
                    <HD SOURCE="HD3">b. Implementation and Use Activities That Are Not an Offering of Health IT</HD>
                    <P>
                        In the ONC Cures Act Final Rule, we noted that there are certain actions taken by health care providers who self-develop health IT for their own use that we do not interpret as them offering or supplying certified health IT to others (85 FR 25799). Specifically, we noted that “some use of a self-developer's health IT may be made accessible to individuals or entities other than the self-developer and its employees without that availability being 
                        <PRTPAGE P="1363"/>
                        interpreted as offering or supplying the health IT to other entities in a manner inconsistent with the concept of `self-developer,' and we provided examples of activities that we do not consider offers (85 FR 25799). Some of the examples we noted (85 FR 25799) were discussed in the context of practices amongst hospitals that purchase commercially marketed health IT as well as self-developer hospitals.
                    </P>
                    <P>
                        While the examples focus on self-developers, these examples would not be considered “offering” health IT regardless of who developed the certified health IT. We also believe there are examples of activities we did not discuss that should not be considered offers of health IT. We, therefore, proposed in paragraph (2) of the offer health IT definition (
                        <E T="03">see</E>
                         88 FR 23860 and 88 FR 23915) to explicitly exclude from the definition of offer health IT certain implementation and use activities of a health care provider or other entity (such as a HIN/HIE, health plan, or public health authority). We refer readers to the HTI-1 Proposed Rule (88 FR 23860) discussions of the activities explicitly listed within the implementation and use activities exclusion from (paragraph (2) of) the definition of offer health IT we have now finalized within § 171.102.
                    </P>
                    <P>We sought comment on this proposal, including whether we should consider revising or refining any of the descriptions or wordings of the functionalities, features, actions, or activities listed in the draft regulation text or whether we should consider explicitly excluding additional activities, actions, or health IT functionalities from what it means to offer health IT.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Comments referencing this exclusion supported the provision. Several commenters recommended specific refinements to the wording or clarifications to the intended scope of the exclusion. Comments were received that recommended the implementation and use activities exclusion encompass each of the following as implementation and use activities:
                    </P>
                    <P>• a health care provider organization or other entity uses pre-production staging or test environments for certified health IT;</P>
                    <P>• use of health IT for purposes of clinical education and improvement activities, including in simulation environments where no care is furnished to actual patients;</P>
                    <P>• a health care provider providing a public health authority's employees or contractors with access to its health IT systems;</P>
                    <P>
                        • providing access to registries and similar data services that are provided by public health authorities, regardless of the route used to request/access/receive data (
                        <E T="03">e.g.,</E>
                         through direct logon to a public health information system, via an app or third-party tool, or via HIN/HIE).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments received on the proposed implementation and use exclusion. In response to comments received, we have revised the wording of the finalized regulation text in the offer health IT definition (as discussed in section IV.B.1 of this rule, above) and have also revised the wording of subparagraphs within paragraph (2) (discussed in the 
                        <E T="03">summary of finalized policy—implementation and use exclusion (paragraph (2))</E>
                         at the end of this section, IV.B.1.b, of this rule).
                    </P>
                    <P>As discussed in section IV.B.1 of this final rule, we reviewed the wording of the offer health IT definition in light of a HITAC comment about providing access to registries and similar data services provided by public health authorities, regardless of the route used to request/access/receive data. We believe the change in the offer health IT definition's wording from “for use by” to “for deployment by or for” better aligns the wording of this definition with the definitions of “API User” and “API Information Source” previously established in § 171.102 by cross-reference to § 170.404(c) (as discussed in section IV.B.1 of this rule, above). We also believe this wording change removed a need to catalog within paragraph (2) all of the various manners in which access, exchange, or use of EHI with public health entities and with others might be accomplished without the individual or entity in the API Information Source role (or equivalent role for non-certified API technology or other manners of access, exchange, or use) meeting the offer health IT definition.</P>
                    <P>The excluded activity descriptions in subparagraphs (2)(ii), (iii), and (iv) are intended to accommodate current heterogeneity in how individuals and entities who deploy health IT (such as health care providers) make EHI available for access, exchange, or use by their information sharing partners. With the minor changes in wording that we mention above, we believe it is clear that subparagraphs (ii) through (iv) of paragraph (2) in conjunction with the revision to the offer health IT definition's wording accomplish this intent. Although subparagraph (2)(ii) discusses APIs and (2)(iii) discusses online portals, we believe that they, when taken together with subparagraph (2)(iv), provide for extensive heterogeneity in the manners of information sharing available now or in the future to those who access, exchange, or use EHI. Moreover, we believe the wording change that we discuss above from “for use by” to “for deployment by or for” also addresses commenters' concerns about whether the offer health IT definition does or does not include interactions with or use of pre-production or other non-production instance(s) of API technology.</P>
                    <P>We also reiterate that, as we stated in the HTI-1 Proposed Rule (88 FR 23860), we do not believe it is necessary to define a production instance because we observe health IT developers, resellers, and customers generally using and understanding a production instance as a particular implementation of a given health IT product that has “gone live” in a production environment (without needing to specify, for this purpose, whether such instance is single- or multi-tenant). Production environments, in turn, we observe are generally understood as being the setting where health IT is implemented, run, and relied on by end users in day-to-day conduct of their profession (such as medicine, nursing, or pharmacy) or other business (such as a payer processing healthcare reimbursement claims or a patient managing their health and care).</P>
                    <P>
                        <E T="03">Summary of finalized policy—implementation and use activities exclusion (paragraph 2):</E>
                         After consideration of comments, we have finalized the proposed implementation and use activities exclusion (paragraph (2)) with revisions. As described in more detail below, we have refined how we describe several types of activities within the exclusion.
                    </P>
                    <P>We have struck from subparagraph (2)(i), (ii), (iii), and (iv) the parenthetical “as defined in this section” following the terms “electronic health information” and “health information network or health information exchange.” The § 171.102 definitions of these terms apply throughout 45 CFR part 171 unless otherwise specified in a particular subpart or section. Thus, the presence or absence of this parenthetical has no effect on the meaning of the subparagraphs noted above and has been removed from the final text.</P>
                    <P>
                        The wording of the activity description in subparagraph (2)(i) has been revised to remove reference to employees or contractors using the individual's or entity's health IT to access, exchange, or use EHI in the course of their employment. Instead, the exclusion lists a variety of types of 
                        <PRTPAGE P="1364"/>
                        activities that an individual's or entity's employees or contractors might do within the scope of their employment or contract duties specific to, or otherwise requiring use of, access to the health IT. The finalized wording of subparagraph (2)(i) explicitly includes use, operation, configuration, testing, maintenance, update, and upgrade activities for an individual's or entity's health IT system(s) or specific application(s) within such systems. It also includes explicit reference to the individual's or entity's employees or contractors giving or receiving training on the health IT.
                    </P>
                    <P>We believe this explicit list of purposes for which employees or contractors might need to use an individual's or entity's deployed health IT provides the clarity some commenters sought regarding a health care provider maintaining non-production instances of health IT for various purposes other than supporting care delivery, documentation, or billing of healthcare. We believe this clarity is achieved by the rewording of subparagraph (2)(i) in complement to the change from “for use by” to “for deployment by or for” others in the offer health IT definition.</P>
                    <P>We have finalized subparagraph (2)(ii) with one revision to its wording: we have removed the parenthetical statement “(whether certified or not)” to improve readability. The deletion of “(whether certified or not)” has no effect on the substance of subparagraph (2)(ii) because the description references API technology in general. As used in subparagraph (ii) of the implementation and use activities exclusion, “application programming interface (API) technology” encompasses “Certified API Technology” as defined in 45 CFR 170.404(c) as well as any other API technology.</P>
                    <P>As proposed, subparagraph (2)(ii) referenced production instances and did not reference pre-production instances. We have retained reference to “production instances” of API technology in the excluded activity description in the finalized definition as the finalized offer health IT definition's wording change from “for use by” to “for deployment by or for” makes it unnecessary to explicitly encompass pre-production instances within subparagraph (2)(ii) of exclusion (2). Specifically, the revised wording of the offer health IT definition makes it clear that deploying any instance(s) of API technology with which independent, outside persons participating in testing activities might interact (in the course of testing or QI activities, or in the role of API User as defined in § 171.404(c) or an analogous role for health IT other than “Certified API Technology” as defined in § 171.404(c)) does not, in and of itself, meet the offer health IT definition. By contrast, the holding out, or the providing or supplying, for deployment by or for other individuals or entities under any arrangement not described in exclusion (3)(iii) of health IT that includes one or more Health IT Module(s) would meet the offer health IT definition, regardless of whether such other individual(s) or entity(ies) were to deploy (or have deployed on their behalf) production instance(s), pre-production instance(s), or any combination of production and pre-production instances of the offered health IT.</P>
                    <P>We have removed from the finalized text of subparagraph (2)(iii) a comma that immediately followed the word “clinicians.” This comma was a typographical error that has been corrected so that the finalized text describes making portals available to any or all of the following: patients, clinicians or other health care providers, or public health entities. We use “public health entities” here to encompass public health authorities, their employees, and their contractor(s) acting in the scope of the contract to the public health authority.</P>
                    <P>Specific to implementation and use activities of entities that need to share information with public health authorities, the revised wording of the offer health IT definition (from “for use by” to “for deployment by or for,” as discussed in section IV.B.1 of this preamble) renders the presence or absence of specific reference in subparagraph (2)(iii) or (iv) to public health authorities' contractors largely moot, because the activities subparagraphs (iii) and (iv) describe (as proposed and finalized) do not involve or include supplying health IT for deployment. However, we proposed the implementation and use activities exclusion (paragraph (2)) for the purpose of giving health care providers (and others) who use certified health IT certainty that implementing certain health IT features and functionalities, as well as engaging in certain practices that are beneficial in an EHR-enabled healthcare environment, will not be considered “offering” certified health IT (regardless of who developed that health IT) (88 FR 23858). Therefore, we have finalized subparagraph (2)(iv) with addition of explicit reference to public health authorities' contractors to better serve subparagraph (2)(iv)'s purpose.</P>
                    <P>
                        By contrast, the activity described in subparagraph (2)(iv) was not proposed to, and as finalized does not, encompass supplying health IT for deployment by or for public health authorities or any other individual(s) or entity(ies). Holding out, providing, or supplying health IT that includes one or more certified Health IT Module(s) for deployment by or for a public health authority will meet the offer health IT definition. (
                        <E T="03">see also</E>
                         the discussion of deployment versus use of health IT in section IV.B.1 of this preamble.)
                    </P>
                    <P>We have modified the wording of subparagraph (v) of exclusion (2) in response to comments seeking explicit clarity regarding the implications of a healthcare facility potentially allowing independent healthcare professionals who furnish services in a healthcare facility to use the facility's health IT for clinical education and improvement activities or to receive training in the use of the healthcare facility's health IT systems. Specifically, following “furnishing, documenting, and accurately billing for that care,” we have added: “participating in clinical education or improvement activities conducted by or in the healthcare facility; or receiving training in use of the healthcare facility's health IT system(s).” With the clarification of the wording of the offer health IT definition (as discussed above in section IV.B.1 of this final rule) from “for use by” to “for deployment by or for” other individuals, we believe the distinction is clear between supplying independent healthcare professionals with health IT to deploy in their outside practice(s) or other endeavors and merely enabling independent healthcare professionals to use a healthcare facility's health IT systems in the course of the professional's engagement in patient care and other activities conducted by or in the healthcare facility.</P>
                    <P>
                        As is the case for subparagraph (2)(iv), we have nevertheless decided to finalize subparagraph (2)(v) to serve the purpose for which we proposed it: giving health care providers (and others) who use certified health IT certainty that implementing certain health IT features and functionalities, as well as engaging in certain practices that are beneficial in an EHR-enabled healthcare environment, will not be considered “offering” certified health IT (regardless of who developed that health IT) (
                        <E T="03">see</E>
                         88 FR 23858 and 88 FR 23860).
                    </P>
                    <P>
                        We believe that patients generally benefit when independent healthcare professionals who practice in a particular facility participate in such activities as training for use of the facility's health IT and other equipment. We believe patients also generally benefit when independent healthcare professionals are able to participate in a facility's clinical education activities, 
                        <PRTPAGE P="1365"/>
                        and we note that this includes the independent clinician conducting or leading clinical education or quality improvement activities in a facility for or with other professionals. Quality improvement and clinical education activities conducted in, but not necessarily by, the healthcare facility could include activities that occur in the facility that are partly or largely conducted by third parties (such as a professional specialty society, Patient Safety Organization (PSO),
                        <SU>241</SU>
                        <FTREF/>
                         Medicare's Quality Innovation Network—Quality Improvement Organization (QIN-QIO),
                        <SU>242</SU>
                        <FTREF/>
                         public health authorities (federal, state, or tribal), or similar entities). Prior to issuing the HTI-1 proposed rule, we had not had indications that healthcare facilities were experiencing uncertainty specific to allowing independent healthcare professionals to use the facility's systems in the course of clinical education or quality improvement activities in the facility—which could, from a health IT perspective, potentially make use of pre-production, production, or a mix of production and pre-production instance(s) of one or more system(s) or application(s).
                    </P>
                    <FTNT>
                        <P>
                            <SU>241</SU>
                             Patient Safety Organizations (PSOs) collect and analyze data voluntarily reported by healthcare providers to help improve patient safety and healthcare quality. PSOs provide feedback to healthcare providers aimed at promoting learning and preventing future patient safety events. Under the Patient Safety and Quality Improvement Act of 2005 (the Patient Safety Act), the Agency for Healthcare Research and Quality (AHRQ) certifies and lists PSOs. (
                            <E T="03">https://pso.ahrq.gov/,</E>
                             retrieved Nov 24, 2023.)
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>242</SU>
                             Administered by CMS, the Quality Improvement Organizations (QIO) Program is one of the largest federal programs dedicated to improving health quality for Medicare beneficiaries. The QIO Program's Quality Innovation Network-QIOs (QIN-QIOs) bring Medicare beneficiaries, providers, and communities together in data-driven initiatives that increase patient safety, make communities healthier, better coordinate post-hospital care, and improve clinical quality. By serving regions of two to six states each, QIN-QIOs are able to help best practices for better care spread more quickly, while still accommodating local conditions and cultural factors. (
                            <E T="03">https://www.cms.gov/medicare/quality/quality-improvement-organizations,</E>
                             retrieved Nov 24, 2023.)
                        </P>
                    </FTNT>
                    <P>Based on comments received in response to our proposing subparagraph (2)(v), we are concerned that codifying subparagraph (2)(v) with wording that explicitly references only furnishing, documenting, and billing for care in the facility would risk creating new uncertainty specific to independent professionals' use of a facility's health IT in the course of quality improvement and clinical education activities in the facility. By explicitly referencing clinical education and quality improvement activities conducted by or in a facility in addition to explicitly referencing furnishing, documenting, and accurately billing for care an independent healthcare professional furnishes to patients in a facility, we believe the finalized wording of subparagraph (v) is beneficial.</P>
                    <P>
                        We reiterate, however, that the holding out, provision, or supply of health IT 
                        <E T="03">for deployment by or for</E>
                         other individual(s) or entity(ies) is not encompassed by any subparagraph of the implementation and use activities exclusion (paragraph (2)). (Again, we refer readers to the discussion of deployment versus use of health IT in section IV.B.1 of this preamble.)
                    </P>
                    <HD SOURCE="HD3">c. Consulting and Legal Services Exclusion From the Offer Health IT Definition</HD>
                    <P>In defining what it means to offer health information technology or offer health IT, we also considered whether it would be beneficial to explicitly establish an exclusion of certain management consulting services that play important roles in some providers' approaches to operational management of their practice, clinic, or facility. The bundled exclusions we proposed in paragraph (3) of the offer health IT definition address “consulting and legal services,” including:</P>
                    <P>
                        • legal services furnished by attorneys that are not in-house counsel 
                        <SU>243</SU>
                        <FTREF/>
                         of the provider (commonly referred to as “outside counsel”);
                    </P>
                    <FTNT>
                        <P>
                            <SU>243</SU>
                             As noted in the HTI-1 Proposed Rule (
                            <E T="03">see</E>
                             88 FR 23860 and 23861 (footnote 407)), in-house counsel would for purposes of the offer definition be considered “employees” of the provider. Furnishing use of the provider's health IT to in-house counsel would no more be an offer of that health IT than would be furnishing use of that same health IT to members of the provider's nursing or medical records staff.
                        </P>
                    </FTNT>
                    <P>• health IT expert consultants' services engaged to help a health IT customer/user (such as a health care provider) define their business needs and/or evaluate, select, negotiate for or oversee configuration, implementation, and/or operation of a health IT product that the consultant does not sell/resell, license/relicense, or otherwise supply to the customer; and</P>
                    <P>• clinician practice or other health care provider administrative or operational management consultant services where the clinician practice or other health care provider's administrative or operational management consulting firm effectively stands in the shoes of the provider in dealings with the health IT developer or commercial vendor, and manages the day-to-day operations and administrative duties for health IT and its use alongside other administrative and operational functions that would otherwise fall on the clinician practice or other health care provider's partners, owner(s), or staff.</P>
                    <P>We refer readers to the HTI-1 Proposed Rule (88 FR 23860 through 23864) for discussion and examples of services that would be excluded under each of subparagraphs (3)(i) through (3)(iii) of the proposed offer health IT definition.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Six commenters referenced this exclusion and expressed general support for the proposal. Some, however, recommended specific modifications or clarifications to the described activities. (Comments specific to each particular subparagraph of paragraph (3), the consulting and legal services exclusion, are summarized below.)
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' sharing their perspectives on this proposal through the public comment process. We have finalized the consulting and legal services exclusion (paragraph 3) with minor clarifications and revisions to each subparagraph, as discussed in detail below under sub-headings specific to each of these subparagraphs.
                    </P>
                    <HD SOURCE="HD3">Legal Services Furnished by Outside Counsel</HD>
                    <P>
                        At subparagraph (3)(i) in the proposed offer health IT definition, we proposed to explicitly exclude legal services furnished by outside counsel (88 FR 23861). As we explained, this proposed exclusion would: codify how we already view, in the context of the definitions currently codified in § 171.102, legal services furnished by outside counsel in certain matters and remove an ambiguity that could, at least in theory, otherwise have unintended effects on how parties may in the future assess the best available options and mechanisms for efficient, cooperative discovery. The proposed exclusion for legal services furnished by outside counsel, like the proposed exclusion of health IT expert consulting services, would focus on the services provided and 
                        <E T="03">not</E>
                         on the type of organization providing them (88 FR 23861).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several comments expressing support for the consulting and legal services exclusion (subparagraph (3)(i)) acknowledged the explicit exclusion of legal services furnished by outside counsel. No comments expressed opposition or concern and no comments recommended particular revisions or clarifications to the legal services description in subparagraph (3)(i).
                        <PRTPAGE P="1366"/>
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         After considering comments received on the offer health IT definition and the consulting and legal services exclusion, we have finalized subparagraph (3)(i) of legal services furnished by outside counsel arrangements. We have, however, revised the text of subparagraph (3)(i) to remove unnecessary words and improve readability. These revisions are detailed below, under the 
                        <E T="03">summary of finalized policy—consulting and legal services exclusion (paragraph (3))</E>
                         heading.
                    </P>
                    <HD SOURCE="HD3">Health IT Consultant Assistance With Selection, Implementation, and Use of Health IT</HD>
                    <P>At subparagraph (3)(ii) in the proposed offer health information technology or offer health IT definition, we proposed to explicitly exclude the work of health IT expert consultants engaged to help a health IT customer/user (such as a health care provider, health plan, or HIN/HIE) do any or all of the following with respect to any health IT product that the consultant does not sell or resell, license or relicense, or otherwise supply to the customer under any arrangement on a commercial basis or otherwise: define their business needs; evaluate or select health IT product(s); negotiate for the purchase, lease, license, or other arrangement under which the health IT product(s) will be used; or oversee configuration, implementation, or operation of a health IT product(s) (88 FR 23862).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Comments regarding the arrangements described in subparagraph (ii) of the consulting and legal services exclusion (paragraph 3) were generally supportive. Several comments recommended clarification as to whether the description encompassed the full scope of informatics consulting practice. One of these comments requested additional detail as to specific domains and tasks within the practice of clinical informatics. Several comments requested clarification as to whether the exclusion applied to a consultant configuring, implementing, or operating health IT on the customer's behalf, or whether it was limited to a consultant overseeing such activities conducted by others.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         After consideration of comments received, we have finalized the description of health IT consultant assistance arrangements in subparagraph (3)(ii) with revised wording to provide additional clarity. Specifically, we have:
                    </P>
                    <P>• clarified the wording of the subparagraph's heading to read “health IT consultant assistance with selection, implementation, and use of health IT” (in the HTI-1 Proposed Rule (88 FR 23915) the omission of the word “with” was a typographical error, which we believe made the heading less readable); and</P>
                    <P>• modified the wording of subparagraph (3)(ii)(C) from “oversee” to “oversee or carry out” so that the exclusion's wording explicitly includes carrying out as well as overseeing configuration, implementation, or operation of health IT products.</P>
                    <P>We believe the revised wording (“oversee or carry out”) in subparagraph (3)(ii)(C) provides certainty and clarity to clinical or biomedical informaticists and other consultants that they can take an active role in configuring, implementing, or operating health IT on the customer's behalf, as well as or instead of overseeing such activities conducted by others, without the consultant's activities meeting the definition of offer health IT.</P>
                    <P>As proposed and now finalized, subparagraph (3)(ii) is agnostic to what specific domains of expertise, or what specific knowledge, skills, or abilities, the consultant might apply to any of the activities described in subparagraphs (3)(ii)(A) through (C) with respect to any health IT product(s) that the consultant does not hold out or supply to the customer under any arrangement. We do not at this time believe it is necessary to limit the applicability of subparagraph (3)(ii) by adding to it a catalog of specific domains in which a health informaticist might be practicing when, or in order to be considered to be, engaged in activities described in any of subparagraphs (3)(ii)(A) through (C) under arrangements consistent with subparagraph (3)(ii).</P>
                    <P>
                        A definition of “health informatics” that is often attributed to the National Library of Medicine 
                        <SU>244</SU>
                        <FTREF/>
                         indicates that “health informatics” is “the interdisciplinary study of the design, development, adoption and application of IT-based innovations in healthcare services delivery, management and planning.”
                        <SU>245</SU>
                        <FTREF/>
                         In our observation, there is today considerable heterogeneity in what health informaticists do, how they do it, and under what arrangements they engage with employers, customers, or clients. Therefore, we believe it would be more cumbersome than helpful to attempt to catalog all, and difficult to identify an appropriately representative sampling, of the tasks that a practitioner of health informatics might oversee or conduct without themselves selling, reselling, licensing, relicensing, or otherwise supplying the customer with health IT that includes one or more Health IT Modules certified under the Program. Such a catalog of tasks or domains of health informatics practice would risk rapidly becoming more limiting than we intend the exclusion to be. Therefore, we decline to do so. Instead, we emphasize that whether any activity or conduct in the course of practicing clinical, biomedical, public health, or any other variation of health informatics (or any other profession) is encompassed by the consulting and legal services exclusion under subparagraph (3)(ii) depends on whether the activity or conduct is consistent with subparagraph (3)(ii).
                    </P>
                    <FTNT>
                        <P>
                            <SU>244</SU>
                             
                            <E T="03">See e.g.,</E>
                             University of Michigan School of Information (
                            <E T="03">https://www.si.umich.edu/programs/master-health-informatics,</E>
                             retrieved 10/25/2023); University of Pittsburgh School of Health and Rehabilitation Sciences blog post “Why Health Informatics Is Its Own Discipline,” Oct. 7, 2021 (
                            <E T="03">https://online.shrs.pitt.edu/blog/why-health-informatics-is-its-own-discipline/,</E>
                             retrieved Oct. 25, 2023).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>245</SU>
                             The definition including this quote appeared in frequently asked questions (FAQs) for “Health Services Research Information Central” updated Apr. 23, 2014, on a web page of the National Library of Medicine's National Information Center on Health Services Research and Health Care Technology (NICHSR). The quote's attribution and citation on that web page read “Procter, R. Dr. (Editor, Health Informatics Journal, Edinburgh, United Kingdom). Definition of health informatics [internet]. Message to: Virginia Van Horne (Content Manager, HSR Information Central, Bethesda, MD). 2009 Aug 16 [cited 2009 Sept 21]. [1 paragraph].” (
                            <E T="03">https://wayback.archive-it.org/7189/20170515160548/https://www.nlm.nih.gov/hsrinfo/hsric_topic_definitions.html,</E>
                             retrieved Oct. 25, 2023).
                        </P>
                    </FTNT>
                    <P>We reiterate that if an individual or entity who engages in an activity or arrangement encompassed by an exclusion from the offer health IT definition happens to otherwise be an § 171.102 actor, that individual or entity is an actor subject to the information blocking provision in section 3022 of the PHSA. If such actor engages in conduct that meets the definition of information blocking in § 171.103, that actor could be subject to enforcement action under the information blocking provision in section 3022 of the PHSA even if they engaged in the practice(s) meeting the information blocking definition in the course of an activity that would not, itself, meet the offer health IT definition.</P>
                    <P>
                        For example, a clinical informaticist who is a doctor of medicine (MD) or osteopathy (DO) might provide consulting services consistent with subparagraph (3)(ii) of the offer health IT definition. The services in this example do not meet the offer health IT definition. Therefore, these services do not cause the informaticist to meet the health IT developer of certified health IT definition. But the clinical informaticist, as an MD or DO, meets the 
                        <PRTPAGE P="1367"/>
                        § 171.102 definition of a health care provider. Thus, the physician in this example is a § 171.102 actor and, were this physician to be determined by OIG to have committed information blocking, the physician would be subject to appropriate disincentives consistent with section 3022(b)(2)(B) of the PHSA.
                    </P>
                    <P>If, however, an individual or entity who practices “health informatics” is not otherwise a § 171.102 health care provider, health IT developer of certified health IT, or HIN/HIE, and would only meet the § 171.102 actor definition by offering health IT chooses to only engage in conduct that does not meet the offer health IT definition, then the individual or entity would not be considered an actor.</P>
                    <HD SOURCE="HD3">Comprehensive and Predominantly Non-Health IT Administrative or Operations Management Services</HD>
                    <P>In subparagraph (3)(iii), we proposed to exclude from the offer health IT definition comprehensive clinician practice or other health care provider administrative or operational management consultant services where the administrative or operational management consulting firm effectively stands in the shoes of the provider in dealings with the health IT developer or commercial vendor, and manages the day-to-day operations and administrative duties for health IT and its use alongside a comprehensive array of other administrative and operational functions that would otherwise fall on the clinician practice or other health care provider's partners, owner(s), or staff (88 FR 23862).</P>
                    <P>Alone among the three proposed exclusions of consulting and legal services arrangements, the exclusion of clinician practice or other health care provider administrative or operational management consulting services would be likely to include arrangements where the health IT deployed by or for the health care provider is supplied to them by the consultant—for example, as part of a comprehensive (“turn key”) package of practice management or other provider administrative or operations management services. In proposing the exclusion from the offer health IT definition of the activities specified in subparagraph(3)(iii), we noted its implication for health care providers' accountability for acts or omissions of their consultants operating under the exception—particularly health care providers' administrative or operational management services consultants—that implicate the definition of information blocking in § 171.103 (88 FR 23862). We refer readers to the HTI-1 Proposed Rule for the rationale for the comprehensive and predominantly non-health IT management services exclusion and explanation of how it operates (88 FR 23862 through 23864). The explanation includes the key factors that differentiate excluded clinician practice or other health care provider administrative or operational management consultant services from IT managed service provider (MSP) services and arrangements (88 FR 23863).</P>
                    <P>The HTI-1 Proposed Rule preamble discussion may include one or more instances of a typographical error in how subparagraph (iii) of exclusion (3) is referenced. This typographical error results in citing the paragraph as (3)(c) instead of (3)(iii). These typographical errors in how the paragraph is cited in the HTI-1 Proposed Rule preamble have no bearing on the substance of the proposal.</P>
                    <P>We solicited comment on this proposal, including specifically whether:</P>
                    <P>• this exclusion is more beneficial than harmful or confusing to the public, including the regulated community (health care providers, other information blocking “actors,” and those who may be more likely to be considered a “health IT developer of certified health IT” in the absence of this exclusion); and</P>
                    <P>• different or additional criteria should factor into differentiating whether a particular arrangement is a practice/operational management services arrangement that happens to include health IT as one of many necessities to operate as a health care provider rather than an arrangement for the supply of health IT that happens to include additional services (88 FR 23864).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments discussing or referencing the proposal to exclude arrangements for comprehensive and predominantly non-health IT clinician practice or other health care provider administrative or operations management services from four commenters. No comments expressed opposition to excluding these activities from the 
                        <E T="03">offer health IT</E>
                         definition. One comment expressed appreciation for the clarity the proposal provides. Two comments recommended revising the exclusion to encompass additional types of arrangements. One comment advocated changing the effect of an activity's exclusion so that an individual or entity that meets the actor definition through other activities (such as by participating as a developer in the Program) would not be considered an actor while engaging in the excluded activity. One commenter shared thoughts specifically in response to the HTI-1 Proposed Rule's prompt for comments on potential benefits and harms of the proposal and potential additional criteria for differentiating between a practice/operational management services arrangement that happens to include health IT and an arrangement for the supply of health IT that happens to include additional services.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Upon consideration of comments received, we have finalized the exclusion of comprehensive and predominantly non-health IT clinician practice or other health care provider administrative or operations management services (subparagraph (iii) of paragraph (3)). We have revised the wording of subparagraph (3)(iii) to improve its readability and clarity. We summarize and respond to specific, detailed comments below.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter advocated that we expand the exclusion to explicitly encompass reselling and hosting certified health IT under a particular vendor-specific model.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         A health care provider who wishes to stand in the shoes of another provider in dealings with the health IT developer or commercial vendor, in managing the day-to-day operations and administrative duties for the health IT, or both, as part of a comprehensive array of predominantly non-health IT administrative and operational functions, can do so without meeting the offer health IT definition. Such conduct would be excluded from the offer health IT definition to the extent the arrangement is consistent with the comprehensive and predominantly non-health IT management services exclusion (subparagraph (3)(iii)). We refer readers to the HTI-1 Proposed Rule explanation of the key factors that differentiate excluded clinician practice or other health care provider administrative or operational management consultant services from IT managed service provider (MSP) services and arrangements (88 FR 23863). Although this discussion of key factors includes an instance of the typographical error whereby subparagraph (3)(iii) is cited as “(3)(c)”, the key factors discussed (88 FR 23863) apply to the arrangements described by subparagraph (3)(iii), as proposed and as now finalized.
                    </P>
                    <P>
                        We discuss in context of the health IT developer of certified health IT definition preamble below (section IV.B.2) additional concerns we would have for a potential policy under which health care providers who choose to sell 
                        <PRTPAGE P="1368"/>
                        or resell certified health IT under additional types of arrangements would not be considered health IT developers of certified health IT. Because of these concerns (discussed in IV.B.2, below) we do not believe it would be appropriate to expand the exclusions from the offer health IT definition to include the vendor-specific resale model cited by this commenter.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some comments cited potential risks, such as of anti-competitive effects or conflicts of interest arising as a result of exclusions potentially encouraging entities in the health sector or beyond to develop consulting operations to supply health IT to customers without the consulting operation being subject to the information blocking regulations, as compared to entities that offer similar services but also meet the health IT developer of certified health IT definition. A comment recommended we ensure sufficient protections are in place but did not suggest specific additional criteria or considerations for determining which arrangements are or should be encompassed by the comprehensive and predominantly non-health IT management services exclusion (subparagraph (3)(iii) and which should instead meet the offer health IT definition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate receiving a response to our request for comment on these points. Subparagraph (3)(iii) explicitly indicates that the consultant providing these services 
                        <E T="03">acts as the agent of the health care provider or otherwise on behalf of the health care provider</E>
                         in dealings with the health IT developer or vendor, day-to-day operations and administration of the health IT, or both. This means that for any (individual or entity) consultant's services to be consistent with subparagraph (3)(iii), the consultant cannot also be the developer of any included health IT items or services. For subparagraph (3)(iii) to apply, the consultant also must explicitly provide comprehensive and predominantly non-health IT administrative or operations management services. Thus, the exclusion cannot apply if the consultant is simply furnishing health IT managed service provider (MSP) services and arrangements or any bundle of exclusively or predominantly health IT items and services to the health care provider.
                    </P>
                    <P>We believe excluded bundles of predominantly non-health IT services are distinguishable from health IT MSP services and arrangements and bundles of predominantly health IT items and services based on their characteristics. For an arrangement to be consistent with the comprehensive and predominantly non-health IT management services exclusion (subparagraph (3)(iii)), the bundle of business administrative and operational management services must demonstrate all of the differentiating factors described at 88 FR 23863:</P>
                    <P>
                        • The individual or entity furnishing the administrative or operational management consulting services acts as the agent of the provider or otherwise on behalf of 
                        <SU>246</SU>
                        <FTREF/>
                         the provider in dealings with the health IT developer(s) or commercial vendor(s) from which the health IT the client health care providers ultimately use is obtained;
                    </P>
                    <FTNT>
                        <P>
                            <SU>246</SU>
                             At 88 FR 23863, we used “stands in the shoes of” instead of “on behalf of, to parallel the wording of the subparagraph as presented in the Proposed Rule. We have updated the statement of this factor here to match the wording of the finalized subparagraph (3)(iii).
                        </P>
                    </FTNT>
                    <P>
                        • The administrative or operational management consulting services must be a package or bundle of services provided by the same individual or entity and under the same contract or other binding instrument, and the package or bundle of services must include a comprehensive array of business administration functions, operations management functions, or a combination of these functions that would otherwise be executed by the health care provider; 
                        <SU>247</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>247</SU>
                             At 88 FR 23863, we referenced one example type of health care provider (clinician practice) and various roles individuals might have within health care provider organizations. We also used the more colloquial “fall on” than “be executed by.” We used that wording at 88 FR 23863 to parallel the wording of the subparagraph as presented in the Proposed Rule. We have updated the statement of this factor here to match the wording of the finalized subparagraph (3)(iii).
                        </P>
                    </FTNT>
                    <P>• The bundle of business administrative and operational management consulting services must include multiple items and services that are not health information technology as defined in 42 U.S.C. 300jj(5); and</P>
                    <P>
                        • The non-health IT services must represent 
                        <E T="03">more than half</E>
                         of each of—
                    </P>
                    <P>○ the person hours per year the consultant (individual or entity) bills or otherwise applies to the services bundle (including cost allocations consistent with Generally Accepted Accounting Principles), and</P>
                    <P>○ the total cost to the client for, or billing from, the consultant per year (including pass-through costs for the health IT items and services).</P>
                    <P>These factors that differentiate comprehensive and predominantly non-health IT management services tailor subparagraph (3)(iii) so that it cannot be satisfied by a simple rebranding of health IT resale models or managed service provider (MSP) services or by tacking a few non-health IT service(s) onto a bundle of predominantly (half or more) health IT items and services. Thus, we believe subparagraph (3)(iii) as finalized is appropriately tailored to guard against misuse of the exclusion in the market today.</P>
                    <P>We recognize, however, the potential for the market to evolve in ways that would increase risk of unintended consequences or abuse of this exclusion from the offer health IT definition. Although we have finalized the exclusion of arrangements consistent with subparagraph (3)(iii) without limiting its applicability based on characteristics, features, or factors beyond those we proposed, we note that we may consider amending the offer health IT definition (including any or all of its exclusions) in future rulemaking in response to experience with the definition in practice or other appropriate factors such as changing market conditions.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter that is a commercial developer of certified health IT advocated that entities otherwise meeting the health IT developer of certified health IT definition should be able to operate a consulting entity that would engage in conduct excluded from the offer health IT definition without the consulting entity's conduct in the course of those activities implicating the developer as an actor. The commenter suggested that a developer could otherwise be at a competitive disadvantage specific to these consulting services compared to consulting entities that engage only in activities excluded from the offer health IT definition and do not otherwise meet the health IT developer of certified health IT definition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Achieving the effect recommended by this comment would require altering the structure and nature of the health IT developer of certified health IT definition rather than the offer health IT definition. Such modification of the health IT developer of certified health IT definition would be beyond the scope of the wording update we proposed in the HTI-1 Proposed Rule (
                        <E T="03">see</E>
                         88 FR 23864 and 23915). Therefore, we interpret the comment primarily as a response to our Request for Information on whether we should consider proposing in future rulemaking any additional exclusions from the offer health IT definition (section IV.C.1 of the HTI-1 Proposed Rule, starting at 88 FR 23873). We summarize and respond to this specific comment here because we believe, in light of comments received from the health IT customer community (including one addressed immediately below), it may be helpful 
                        <PRTPAGE P="1369"/>
                        to both health IT developers of certified health IT and their customers for us to provide an overview of certain features and implications of the information blocking regulations within which the finalized subparagraph (3)(iii) of the offer health IT definition appears.
                    </P>
                    <P>A baseline feature of information blocking regulations in place since the ONC Cures Act Final Rule (85 FR 25642) is that the health information network or health information exchange (HIN/HIE) definition is currently the only § 171.102 actor type definition that is functional. As we stated in the ONC Cures Act Final Rule, “the individual or entity would be considered a HIN/HIE under the information blocking regulations for any practice they conducted while functioning as a HIN/HIE” (85 FR 25802). In contrast, both the health care provider and health IT developer of certified health IT definitions in § 171.102 are categorical, in the sense that an individual or entity either meets one of these definitions or they do not. For example, an individual or entity that meets the health IT developer of certified health IT definition in any of its activities is considered to be a health IT developer of certified health IT for any of its practices that otherwise meet the information blocking definition in 45 CFR 171.103—regardless of whether health IT involved in a specific practice is certified. To read more about the health IT developer of certified health IT definition's scope, including applicability of the Cures Act's information blocking provision to a developer's non-certified health IT, please see the ONC Cures Act Final Rule preamble starting at 85 FR 25795.</P>
                    <P>We recognize that in a variety of circumstances developers and offerors of certified health IT have business lines or other entities that market various services also marketed by competitor entities that do not develop or offer any certified health IT. We also recognize, and would encourage customers to be aware, that any individual or entity that (1) offers health IT products or consulting services in a way that satisfies the exclusion, (2) does not engage in any other conduct within the offer health IT definition, and (3) does not otherwise meet the § 171.102 actor definition would not be subject to the information blocking regulations.</P>
                    <P>We believe any perceived competitive disadvantage a “health IT developer of certified health IT” may experience as a result of meeting the definition in § 171.102 is offset by customers' potential preferences to receive services from consultants who are § 171.102 actors. For example, in choosing among otherwise competitive bids from a non-actor and a health IT developer of certified health IT to serve in a specific consulting role, a customer might weigh as favorable to a vendor or consultant that is a § 171.102 actor the fact that the actor could be subject to enforcement action under section 3022 of the PHSA if (except as required by law or covered by an exception) the actor engages in conduct they know or should know is likely to interfere with the access, exchange, or use of EHI. We also refer readers to the discussion in the ONC Cures Act Final Rule (85 FR 25795 through 25796) of a related concern about the potential impact of the Cures Act's information blocking provision (42 U.S.C. 300jj-52) on health IT developers' decisions to participate in the Program.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter expressed concern about the risk of customers being uncertain as to which entities offering consulting services excluded from the 
                        <E T="03">offer health IT</E>
                         definition are subject to information blocking regulations and which are not, and about other entities' ability to support needs for data sharing within the healthcare space.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the commenter sharing this concern. We recognize that whether a consultant has the skills and expertise to deliver what the customer needs and expects for data sharing and other activities involving or relying on data, is a foundational question. Answering it, we believe, will continue to be something customers do by assessing prospective consultants' qualifications against their specific needs and priorities. Knowing that a consultant is an actor subject to information blocking regulations is a useful piece of information for customers to have, but a consultant meeting the § 171.102 actor definition does not guarantee the consultant has the level of particular knowledge, skills, abilities, or other capacity that the customer wants or needs from a consultant or other vendor.
                    </P>
                    <P>
                        We also recognize that customers who prefer to obtain services that are excluded from the definition of offer health IT from an entity that is subject to the information blocking regulations may need to engage in fact-finding to ascertain the status of entities that provide these services. We note that it may be somewhat easier to identify the actor status of a consultant where the consultant is also a developer participating in the Program, or a health care provider, than where they are not. This is because, for example, both individual and organizational health care providers must typically be licensed in jurisdiction(s) where they furnish healthcare. Most health care providers in the United States will also have a National Provider Identifier (NPI). Online directories of licensed health care providers are available from or for U.S. states, and CMS supports an online search utility for the NPI registry (available to the public free of charge at 
                        <E T="03">https://npiregistry.cms.hhs.gov/search</E>
                        ). Similarly, a search of ONC's Certified Health IT Products List (CHPL) (
                        <E T="03">https://chpl.healthit.gov/#/search</E>
                        ) will indicate whether an entity has listed under its name one or more Health IT Module(s) certified under the Program. By contrast, an entity that only resells Health IT Module(s) without having responsibility for the certification status of any such Health IT Module(s) will not be listed on the CHPL. It is also important to remember that entities' choices to engage in different lines of business under different names may mean that the name under which consulting services are furnished differs from the name(s) under which: a developer of certified health IT is associated with any CHPL-listed product(s); or an individual or entity that meets the § 171.102 health care provider definition may be listed in any registry, listing, or database of individual and organizational health care providers. Therefore, a customer may need to refer to additional sources of information, including those provided by the prospective consultant, and may want to consider addressing the consultant's § 171.102 actor status in the process of selecting the consultant or contracting with the consultant for their services (such as through representations and warranties).
                    </P>
                    <P>One expectation we have for the improved clarity provided by the offer health IT definition is that it will help customers to differentiate between consultants who clearly are § 171.102 actors and those who might not be actors. With this clarity, we believe customers will be in a better position to assess what additional information, representations, or warranties they will require from a consultant before making or finalizing a decision to engage the consultant.</P>
                    <P>
                        <E T="03">Summary of finalized policy—consulting and legal services exclusion (paragraph (3)):</E>
                         After considering comments received, we have finalized the substance of the consulting and legal services exclusion. The finalized text of paragraph (3) includes minor revisions to subparagraphs (i), (ii), and (iii) to improve clarity, address a typographical error, and improve readability (as discussed above):
                    </P>
                    <P>
                        • Revised the second sentence of subparagraph (i) to remove unnecessary 
                        <PRTPAGE P="1370"/>
                        words, increase precision, and improve readability, as follows:
                    </P>
                    <P>○ Removed unnecessary words from “if or when facilitating limited access or use of the client's health IT or the EHI within it,” resulting in the revised phrase reading “when facilitating limited access or use of the client's health IT.”</P>
                    <P>○ Revised the phrase “to independent expert witnesses engaged by counsel” for readability and precision to read, as revised: “by independent expert witnesses engaged by the outside counsel.”</P>
                    <P>○ Revised the final phrase of the sentence from “as necessary or appropriate to legal discovery” to “as appropriate to legal discovery.”</P>
                    <P>• Revised the wording of the subparagraph (3)(ii) heading to read “health IT consultant assistance with selection, implementation, and use of health IT,” correcting the typographical error that had omitted “with” from the text as published in the HTI-1 Proposed Rule (88 FR 23915).</P>
                    <P>• Revised the wording of subparagraph (3)(ii) to improve readability by removing unnecessary reference to services being potentially provided by an individual or a firm, and to “expert.” As discussed in response to comments, subparagraph (3)(ii) applies to the activities it describes. Application of subparagraph (3)(ii) does not depend on the consultant having or applying specific type(s) or level(s) of expertise, knowledge, or skills in furnishing expert services to help the customer do (or do for the customer) the activities described in subparagraph (3)(ii)(A) through (C). The revision is from the HTI-1 Proposed Rule's wording “. . . provided by an individual or firm when furnishing expert advice and consulting services to a health IT customer or user that help the customer or user, or on the customer's behalf, do . . .” to “. . . advice and consulting services furnished to a health IT customer or user to do (or on behalf of a customer or user does).”</P>
                    <P>• Revised wording of subparagraph (3)(ii)(A) to improve readability, from “define the customer or user business needs; evaluate or select health IT product(s),” as presented in the HTI-1 Proposed Rule, to the finalized wording of: “define the business needs of the customer or user or evaluate health IT product(s) against such business needs, or both.”</P>
                    <P>• In response to public comments, modified the wording of subparagraph (3)(ii)(C) from “oversee” to “oversee or carry out” so that, on its face, the wording provides immediate and explicit clarity that the exclusion encompasses carrying out as well as overseeing configuration, implementation, or operation of health IT products.</P>
                    <P>• To improve readability of subparagraph (3)(iii), we have revised its wording in the following ways:</P>
                    <P>○ Split the paragraph into two sentences instead of one. The second sentence, as finalized, opens with “To be consistent with this subparagraph, such services must be furnished” to connect this to the preceding paragraph and ensure it remains clear that services are not consistent with subparagraph (3)(iii) unless they are furnished as part of a comprehensive array of predominantly non-health IT services (as discussed above, in responses to comments).</P>
                    <P>○ From the first revised sentence, removed unnecessary reference to clinician practice and other unnecessary words to improve readability. This change is from “provided by an individual or entity when furnishing a clinician practice or other health care provider administrative or operational management consultant services where the management consultant acts as the agent of the provider or otherwise” to the finalized wording: “when an individual or entity furnishes a health care provider with administrative or operational management consultant services and the management consultant acts as the agent of the provider or otherwise.”</P>
                    <P>○ Replaced in the first finalized sentence of the subparagraph the phrase “stands in the shoes of the provider” with less colloquial phrase “acts on behalf of the provider.”</P>
                    <P>○ Revised description of dealings with health IT developers and vendors to strike unnecessary adjective (“commercial”) and improve facial clarity that the dealings could be with one or more developers or vendors. This change in text is from “in dealings with the health IT developer or commercial vendor” to “in dealings with one or more health IT developer(s) or vendor(s).”</P>
                    <P>○ At the end of what is, as finalized, the first sentence of the subparagraph, we replaced “and/or in managing the day-to-day operations and administrative duties for the health IT,” with “or managing the day-to-day operations and administrative duties for the health IT, or both.”</P>
                    <P>○ Replaced in the second clause of the finalized second sentence of the subparagraph the phrase “fall on” with less colloquial phrase “be executed by” and struck unnecessary reference to a specific type of health care provider entity, and unnecessary reference to different roles within provider organizations. The affected portion of the subparagraph as presented in the HTI-1 Proposed Rule read: “as part of a comprehensive array of predominantly non-health IT administrative and operational functions that would otherwise fall on the clinician practice or other health care provider's partners, owner(s), or staff.” As a result of the revisions described here, the second sentence of the subparagraph reads as a whole: “To be consistent with this subparagraph, such services must be furnished as part of a comprehensive array of predominantly non-health IT administrative and operational functions that would otherwise be executed by the health care provider.”</P>
                    <P>
                        We reiterate here, because we believe it is worth amplifying, a point we noted in the HTI-1 Proposed Rule (88 FR 23862) specific to the comprehensive and predominantly non-health IT management services arrangements (subparagraph (3)(iii)). That point is its implication for health care providers' accountability for acts or omissions of health care providers' administrative or operational management services consultants operating under the exception that implicate the definition of information blocking in § 171.103: where an administrative or operations management services firm would not be considered to offer health IT for which they contract on behalf of one or more practices (or facilities or sites of care) 
                        <E T="03">because they are acting as the provider's agent or otherwise standing in the shoes of the provider</E>
                         in selecting and contracting for a variety of services and supplies—including, but not limited to, the health IT that includes at least one certified Health IT Module—we would view the provider as retaining accountability for any information blocking conduct that the management services company perpetrates while thus acting on the provider's behalf. We recognize this may have implications for how providers may wish to structure administrative and operational services contracts in the future, potentially including a provider seeking representations and warranties giving the provider assurance that the administrative or operations management services company will not, without the provider's direction, knowledge, or approval, engage in any practice not required by law or covered by an information blocking exception that is likely to interfere with access, exchange, or use of EHI and could be unreasonable. However, subparagraph (3)(iii) of the consulting and legal services exclusion from the offer health 
                        <PRTPAGE P="1371"/>
                        IT definition is not intended to have the effect of regulating or otherwise interfering with contracting relationships between health care providers and entities that do, or might, furnish them with practice, facility, location, or site management consulting and operational services packages.
                    </P>
                    <P>
                        We also remind, again, any individual or entity otherwise meeting the § 171.102 actor definition that engaging in activities that are explicitly excluded from the offer health IT definition under paragraph (1), (2), or (3), will 
                        <E T="03">not</E>
                         change the fact that they are a § 171.102 actor. Where an individual or entity meets the actor definition, that actor's having also engaged in any one or more activities that satisfies an exclusion from the offer health IT definition does not mean the individual or entity is no longer an actor. The fact that an actor may engage in some conduct that is consistent with an explicit exclusion from the offer health IT definition does not mean that conduct on the actor's part is not subject to the information blocking definition. The fact that particular conduct of an individual or entity meets any exclusion from the offer health IT definition only means that specific conduct does not meet the definition of offer health IT.
                    </P>
                    <HD SOURCE="HD3">2. Health IT Developer of Certified Health IT: Self-Developer Health Care Providers</HD>
                    <P>
                        For reasons discussed in the ONC Cures Act Final Rule (85 FR 25799 through 25800), health care providers who self-develop certified health IT “for their own use” were excluded from the health IT developer of certified health IT definition. However, under that definition, if a health care provider responsible for the certification status of any Health IT Module(s) were to offer 
                        <E T="03">or supply</E>
                         those Health IT Module(s) on any terms to other entities for those entities' use in their own independent operations, that would be inconsistent with the concept of the health care provider self-developing health IT “for its own use.” As we explained in the ONC Cures Act Final Rule (at 85 FR 25799), we use the term “self-developer” in this context as the term has been used in the ONC Health IT Certification Program (Program) and as described in section VII.D.7 of the Cures Act Proposed Rule (at 84 FR 7507).
                    </P>
                    <P>
                        In the HTI-1 Proposed Rule, informed by our proposal to define “offer health IT,” we proposed to modify the health IT developer of certified health IT definition in § 171.102. To ensure it would be immediately clear from the face of the regulations' text that we had put all health care providers that engage in activities consistent with the exclusions in paragraphs (1) through (3) of the offer health IT definition on the same footing regardless of who develops the health IT involved in these activities, we proposed to replace in the health IT developer of certified health IT definition the phrase “other than a health care provider that self-develops health IT for its own use” with the phrase “other than a health care provider that self-develops health IT not offered to others” (
                        <E T="03">See</E>
                         88 FR 23864).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A majority of comments specific to this proposal supported the proposal. Several comments stated that self-developer health care providers should not be considered health IT developers of certified health IT. Several comments stated that self-developer health care providers who offer health IT should be included health IT developers of certified health IT definition alongside other individuals and entities that offer certified health IT.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate all comments received. Having considered the comments, we have finalized our proposal to align the self-developer health care provider exclusion from the health IT developer of certified health IT definition with our finalized definition of “offer health IT.” Stated another way, health care providers who self-develop certified health IT that is not offered to others are excluded from the health IT developer of certified health IT definition unless they “offer health IT” as now defined in § 171.102. We have made one revision to the wording of the finalized updated text of the definition for readability, specifically from “other than a health care provider that self-develops health IT not offered to others” to “other than a health care provider that self-develops health IT that is not offered to others.” We summarize and respond to additional comments related to the health IT developer of certified health IT definition below.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments advocating that we exclude all providers who host EHRs for other providers (sometimes characterizing it as extending the host provider's EHR) from the health IT developer of certified health IT definition. These comments have been discussed in section IV.B.1 because several of them discussed this recommendation as an extension, clarification, or addition to the proposed exclusions from the offer health IT definition. Some commenters, however, connected the suggestion to the health IT developer of certified health IT definition. Commenters' rationales for excluding from the health IT developer of certified health IT definition health care providers who “extend their EHRs” or otherwise provide certified health IT to other providers included: health care providers are already actors under the information blocking regulations (§ 171.102); recipient providers would be unable to afford interoperable health IT obtained from other sources; and the developer should be held accountable for design defects in health IT. Several other commenters, representing the health care provider as well as the ONC Health IT Certification Program-participating developer perspectives, explicitly supported our proposal to have all entities that offer health IT (as we have defined such action) continue to meet the definition of health IT developers of certified health IT regardless of whether such health IT was self-developed or obtained from a third-party developer.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Whether done by a health care provider or anyone else, hosting EHR systems, otherwise providing or supplying health IT items and services, or holding out any certified health IT to health care providers generally meets the offer health IT definition. Such actions are excluded from the offer health IT definition only when and to the extent it is consistent with subparagraph (3)(iii) of the offer health IT definition. Any individual or entity, regardless of whether they also meet the § 171.102 definition of health care provider, who engage in conduct meeting the offer health IT definition meet the health IT developer of certified health IT definition on the basis of that conduct.
                    </P>
                    <P>We had not proposed, and we have not made, revisions to “carve out” health care providers who offer health IT from the health IT developer of certified health IT definition. We included in section IV.C.1 of the HTI-1 Proposed Rule (88 FR 23873) a request for information on additional exclusions from the offer health IT definition but did not propose to exclude supply of health IT for deployment by or for others from the offer health IT definition based on the supplier being a health care provider. Further, as noted above, we received comments supporting the health IT developer of certified health IT approach we proposed. Therefore, any further exclusions from the offer health IT definition are deferred for future consideration.</P>
                    <P>
                        Regarding concerns about design flaws in the software created by the developer of certified health IT, as a § 171.102 actor, the developer would be subject to information blocking penalties for software design flaws to the extent such flaws constitute information blocking. As we did in the ONC Cures Act Final Rule (
                        <E T="03">see</E>
                         85 FR 
                        <PRTPAGE P="1372"/>
                        25798 through 25799), we again refer commenters concerned about holding offerors that do not develop health IT accountable for the conduct of the developer (or others) to section 3022(a)(6) of the PHSA, which states that the term “information blocking,” with respect to an individual or entity, shall not include an act or practice other than an act or practice committed by such individual or entity. Where the individual or entity that develops health IT is different from the individual or entity that offers certified health IT, each such individual or entity is only liable for the acts and practices that it commits.
                    </P>
                    <P>In the ONC Cures Act Final Rule (85 FR 25798-25800), we explained that any that any individual or entity that develops health IT, except for health care providers that self-developed certified health IT for their own use, meet the definition of health IT developer of certified health IT while they have one or more Health IT Modules certified under the ONC Health IT Certification Program. We also explained that individuals or entities meet the health IT developer of certified health IT definition if they offer certified health IT. This remains true with the conclusion of this rulemaking. Under the policies finalized in this rule, any individual or entity, including a self-developer health care provider or any other health care provider, that offers health IT (as defined in § 171.102) meets the definition of health IT developer of certified health IT.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter requested that we clarify what the term health care provider means as used within the health IT developer of certified health IT definition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The term health care provider is defined for purposes of the information blocking regulations in 45 CFR 171.102. To help interested parties better understand the definition, we make information blocking resources available through our website, 
                        <E T="03">HealthIT.gov</E>
                        . These resources include a fact sheet titled “Health Care Provider Definition” that provides, in a single document, a copy of the full text of the health care provider statutory definition (PHSA section 3000) cited in § 171.102 and the text of statutory cross-references within the PHSA section 3000 definition of health care provider.
                        <SU>248</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>248</SU>
                             
                            <E T="03">Health Care Provider Definition and Cross-Reference Table,</E>
                             available at: 
                            <E T="03">https://www.healthit.gov/sites/default/files/page2/2020-08/Health_Care_Provider_Definitions_v3.pdf</E>
                             (Retrieved Jun 28, 2023.)
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Summary of finalized policy—health IT developer of certified health IT definition:</E>
                         After consideration of comments received, we have finalized the revision to the definition substantively as proposed. We have made a non-substantive change to the wording of the finalized revised definition of health IT developer of certified health IT in comparison to the HTI-1 Proposed Rule; specifically, in the clause excluding self-developer health care providers to the extent their self-developed health IT is not offered to others. In the HTI-1 Proposed Rule, that clause read: “other than a health care provider that self-develops health IT not offered to others.” As finalized, we added “that is” immediately before “not offered to others” to improve readability of the finalized text.
                    </P>
                    <P>We emphasize that any individual or entity that chooses to offer health IT (as defined in § 171.102) will meet the finalized revised § 171.102 health IT developer of certified health IT definition regardless of who developed the certified health IT that the individual or entity offers to others, and regardless of whether the health IT is offered at or below cost, market rate, or other benchmark price for the same or similar health IT items or services. This includes individuals and entities that offer health IT while also meeting the definition of health care provider, as both terms are defined in § 171.102, regardless of whether such individuals or entities also self-develop any health IT (certified or otherwise) deployed only within their own organization or operations. Regarding health care providers who might engage in activities consistent with one or more exclusion(s) from the offer health IT definition without also engaging in activities or arrangements that meet the offer health IT definition, we note that all such health care providers will stand on the same footing regardless of whether they also self-develop health IT that is not offered to others.</P>
                    <HD SOURCE="HD3">3. Information Blocking Definition</HD>
                    <P>As finalized in the ONC Cures Act Final Rule (85 FR 25642) and the Cures Act Interim Final Rule (85 FR 70085), the information blocking definition (§ 171.103) and the Content and Manner Exception (§ 171.301(a)) were limited for a period of time to a subset of EHI that was narrower than the EHI definition finalized in the ONC Cures Act Final Rule in § 171.102. The narrower subset included only the EHI identified by the data elements represented in the United States Core Data for Interoperability (USCDI) for the first 18 months (until May 2, 2022) after the applicability date for 45 CFR part 171 (November 2, 2020) (85 FR 25792). The Cures Act Interim Final Rule extended the applicability date of 45 CFR part 171 to April 5, 2021 (85 FR 70069). This extended the end of the first 18 months of applicability of 45 CFR part 171 until October 6, 2022 (85 FR 70069).</P>
                    <P>Because October 6, 2022, has passed, we proposed to revise the information blocking definition (§ 171.103) to remove the paragraph designating the period of time for which the information blocking definition was limited to EHI that consists of the data elements represented in the USCDI (88 FR 23864 and 88 FR 23916). This time period designation was codified in § 171.103(b), as finalized in 2020, and removal of this paragraph allows for redesignation of remaining paragraphs within § 171.103 as shown in the HTI-1 Proposed Rule (at 88 FR 23916).</P>
                    <P>Similarly, because we included the same date in two paragraphs of the Content and Manner Exception (§ 171.301(a)(1) and (2)), we proposed to revise § 171.301 to remove the existing § 171.301(a)(1) and (2) as no longer necessary (88 FR 23864 through 23865 and 88 FR 23916). The proposed revised version of § 171.301 refers simply to EHI. We further proposed to renumber several of the existing provisions in § 171.301 accordingly and rename the exception as the “Manner” exception.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Comments received on our proposal to remove obsolete text from the information blocking definition (§ 171.103) generally supported this proposal. Comments noted that the information blocking definition prevents practices that hinder access to EHI, supports improved access to EHI for patients and health care providers, facilitates interoperability and encourages actors to prioritize interoperability, and promotes transparency and accountability in the healthcare ecosystem. A commenter stated the information blocking regulations are beneficial to underserved, underrepresented patient populations and the health care providers who serve them. This commenter advocated for collaborative efforts among various parties interested in information sharing, characterizing such efforts as crucial to ensuring that the information blocking regulations effectively support the goal of equitable access to high-quality healthcare for underserved populations. No commenters opposed this proposal. However, some commenters did note general concerns about the importance of balancing information sharing goals with patient privacy and data security.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' feedback and have finalized the update to the information blocking definition 
                        <PRTPAGE P="1373"/>
                        (§ 171.103), as proposed. The topic of balancing information sharing goals with patient privacy and security of patients' health information is out of scope for this proposal, but it was also raised in comments on other proposals. We discuss, at the beginning of section IV of this final rule (above), comments raising general concerns about a perceived conflict between the goals of maximizing information sharing and appropriately protecting patients' privacy interests. We agree that information sharing can help improve many aspects of health care for all patients throughout the United States. We look forward to continued engagement with actors, patients, and others who support information sharing that contributes to improved care and health for individuals, families, and communities.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received one comment that expressed concern about requirements to share mental health notes that were historically blocked from the rest of the record. The comment identified as an issue having all health care providers being able to access all mental health notes when they may not be immediately relevant to the patient at the point of care.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In the HTI-1 Proposed Rule, we did not propose to modify existing exclusions from the § 171.102 definition of EHI for purposes of the information blocking regulations. Psychotherapy notes as defined in the HIPAA Privacy Rule at 45 CFR 164.501 are explicitly excluded from the 45 CFR 171.102 definition of electronic health information (EHI) for purposes of the information blocking regulations. We have posted on our website information resources to help actors understand the EHI definition and consider whether particular data is EHI for purposes of 45 CFR part 171 (see 
                        <E T="03">https://www.healthit.gov/topic/information-blocking</E>
                        ).
                    </P>
                    <P>We note, and remind actors, that persons who engage in inappropriate uses and disclosures of individuals' health information may be violating other laws, including, but not limited to, the HIPAA Privacy Rule, 42 CFR part 2, or state or tribal laws. Persons using or disclosing individuals' health information in violation of one or more such law(s) would be subject to the consequences for violating those laws.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter advocated for further revision of the information blocking definition to specify who must be affected by a practice that is otherwise consistent with the definition in order for the practice to be considered information blocking. The comment suggested as an example adding to paragraph (2)(b) of § 171.103 an explicit statement that the action can affect EHI access by physicians as well as by patients.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We did not propose such a revision in § 171.103 and decline to adopt it here. We reiterate that an actor's practice meeting the information blocking definition is considered to be information blocking regardless of whether it affects access, exchange, or use of EHI by a patient, health care provider, health plan, or other person (as defined in § 171.102) that seeks access, exchange, or use of EHI for any permissible purpose (as defined in § 171.102).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter requested we retain “Content and Manner” as the title of the exception codified in § 171.301 and retain wording specific to limiting the content fulfilled for a request to recognize the potential for an actor to be able to fulfill access, exchange, or use of some, but not all, EHI in a particular requested manner. Another commenter characterized our proposal to remove reference to the period of time and limited EHI in § 171.301 as removing a safe harbor protection for limiting the content of a response. This commenter stated that an actor may be able to satisfy § 171.301 for only some of the EHI requested. This commenter also stated that the proposed revision to § 171.301 creates uncertainty as to whether the Manner Exception can be satisfied where an actor can fulfill access, exchange, or use of only some EHI in the manner requested or in an alternative manner consistent with § 171.301.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We decline to retain the prior title of the Manner Exception. We note that the “content” condition we have removed from regulatory text through this final rule has been moot since October 6, 2022, and we did not propose to re-instate it in the HTI-1 Proposed Rule. In section IV.A, we discuss an example situation where multiple exceptions could be used to provide an actor with certainty that their practices in responding to a request for access, exchange, or use of EHI will not be considered to be information blocking. Similarly, an actor might be able to satisfy the Manner Exception for only some of the EHI requested in a particular situation. In such instances, an actor may want to consider whether another exception is applicable to any other requested EHI.
                    </P>
                    <P>
                        <E T="03">Summary of finalized policy:</E>
                         After consideration of comments, we have finalized the proposed removal of references to the USCDI, as well as the time period designation, from §§ 171.103 and 171.301. We have also finalized corresponding redesignations of paragraphs, as proposed.
                    </P>
                    <HD SOURCE="HD2">C. Exceptions</HD>
                    <HD SOURCE="HD3">1. Infeasibility</HD>
                    <HD SOURCE="HD3">a. Infeasibility Exception—Uncontrollable Events Condition</HD>
                    <P>
                        We established the Infeasibility Exception in the ONC Cures Act Final Rule (85 FR 25865 through 25870, 85 FR 25958; 45 CFR 171.204). The Infeasibility Exception includes conditions under which an actor's practice of not fulfilling requests for EHI access, exchange, or use due to infeasibility will not be considered information blocking. One of the conditions of the Infeasibility Exception, finalized by the ONC Cures Act Final Rule in § 171.204(a)(1), is the 
                        <E T="03">uncontrollable events</E>
                         condition. Under the 
                        <E T="03">uncontrollable events</E>
                         condition, an actor's practice of not fulfilling a request to access, exchange, or use EHI that is infeasible for the actor to fulfill as a result of events beyond the actor's control (listed in § 171.204(a)(1)) will not be considered information blocking provided such practice also meets the condition in § 171.204(b). In the HTI-1 Proposed Rule, we proposed to revise § 171.204(a)(1) to add clarity to the 
                        <E T="03">uncontrollable events</E>
                         condition (88 FR 23865).
                    </P>
                    <P>
                        In the HTI-1 Proposed Rule (88 FR 23865), we reminded readers that under the 
                        <E T="03">uncontrollable events</E>
                         condition, an actor's practice of not fulfilling a request to access, exchange, or use EHI as a result of a natural or human-made disaster, public health emergency, public safety incident, war, terrorist attack, civil insurrection, strike or other labor unrest, telecommunication or internet service interruption, or act of military, civil or regulatory authority (§ 171.204(a)(1); 85 FR 25874) will not be considered information blocking provided such practice also meets the condition in § 171.204(b). We explained that the fact that an uncontrollable event specified in § 171.204(a)(1) occurred is not a sufficient basis alone for an actor to meet the 
                        <E T="03">uncontrollable events</E>
                         condition of the Infeasibility Exception. Rather, the use of the words “due to” in the 
                        <E T="03">uncontrollable events</E>
                         condition (paragraph (a)(1) of § 171.204) was intended to convey, consistent with the Cures Act Proposed Rule, that the actor must demonstrate a causal connection between the actor's inability to fulfill access, exchange, or use of EHI and the uncontrollable event. As we illustrated in the HTI-1 Proposed Rule (88 FR 23865), a public health emergency is listed as an uncontrollable event under § 171.204(a)(1). If the federal 
                        <PRTPAGE P="1374"/>
                        government or a state government were to declare a public health emergency, the mere fact of that declaration would not suffice for an actor to meet the condition. To meet the condition, the actor would need to demonstrate that the public health emergency actually caused the actor to be unable to provide access, exchange, or use of EHI for the facts and circumstances in question. The emergency need not be the 
                        <E T="03">only</E>
                         cause of a particular incapacity, but the actor needs to demonstrate that the public health emergency did in fact negatively impact the feasibility of that actor fulfilling access, exchange, or use in the specific circumstances where the actor is claiming infeasibility.
                    </P>
                    <P>
                        While the 
                        <E T="03">uncontrollable events</E>
                         condition (§ 171.204(a)(1)) has always required causal connection between the actor's inability to fulfill the request and the natural or human-made disaster, public health emergency, public safety incident, war, terrorist attack, civil insurrection, strike or other labor unrest, telecommunication or internet service interruption, or act of military, civil or regulatory authority, we proposed to revise the condition by replacing the words “due to” with “because of” (88 FR 23865). We welcomed comments on this proposal, including whether alternative or additional refinements to the wording of the condition may make the causal connection requirement more immediately obvious from the face of the text in § 171.204(a)(1) (88 FR 23865).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         In general, commenters expressed support for clarifying the 
                        <E T="03">uncontrollable events</E>
                         condition by stating that the actor's inability to fulfill the request is “because of” one of the events listed. Commenters noted that the extra clarity adds certainty for actors and demonstrates a clear causation requirement. Some commenters supported the change but noted that “due to” and “because of” mean the same thing and the change would not have any resulting implications for actors. Another commenter agreed with the intent but did not believe that the change of wording from “due to” to “because of” provides any more clarity. This commenter asked what change in impact or obligation stemmed from the change, recommending a clear statement of the causal connection between the uncontrollable event and the impact on the actor. A commenter requested clarification as to how ONC believes the “due to” and “because of” differ in terms of implications for—or obligations now expected of— actors. A commenter recommended we make a clear statement about the causal connection between the uncontrollable event and the impact on the actor but did not suggest where, or in what words, we should consider making the statement.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support expressed by many commenters and as discussed more fully below; we have finalized a revision of § 171.204(a)(1) with modifications to the regulation text to provide additional clarity. As noted in the preamble to the HTI-1 Proposed Rule, the words “due to” convey that the actor must demonstrate a causal connection between not providing access, exchange, or use of EHI and the uncontrollable event (88 FR 23865). We proposed to change the term to “because of” to provide further clarity. The revised language was not intended to change the substance of the condition, its implications, or what would be required of an actor for purposes of meeting the condition.
                    </P>
                    <P>
                        We did not receive comments suggesting specific additional refinements to the condition's text, or recommending specific alternative wording for “because of,” to make the causal connection requirement more immediately obvious from the text of the 
                        <E T="03">uncontrollable events</E>
                         condition (§ 171.204(a)(1)). However, having considered commenters' feedback, adding text to the finalized revision to § 171.204 will help actors and other interested persons immediately recognize that a causal connection is required between the uncontrollable event and the infeasibility of the actor's fulfilling a request for EHI access, exchange, or use. We have, therefore, finalized the proposed revision to § 171.204(a)(1) with the additional clause “that in fact negatively impacts the actor's ability to fulfill the request” at the end of the condition. This additional text is consistent with our statement in the preamble of the HTI-1 Proposed Rule that “the actor must demonstrate a causal connection between not providing access, exchange, or use of EHI and the uncontrollable event” (88 FR 23865). We intend for this additional clause to reinforce clarity that the actor must demonstrate an actual negative impact of the uncontrollable event on their ability to fulfill the requested access, exchange, or use of EHI for the 
                        <E T="03">uncontrollable events</E>
                         condition to be met. To reiterate, the finalized change to the wording of § 171.204 is only intended to improve clarity for actors and other interested parties in comparison to the previous wording rather than to make any change to the substance of the policy that it codifies.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter recommended that ONC expand the definitions within the 
                        <E T="03">uncontrollable events</E>
                         condition to include impediments of data access, exchange, or use because of any disaster or emergency declared by an authorized governmental entity, noting that in addition to declared emergencies, this would include response and recovery periods associated with natural disasters that impacted the availability of providers' information systems or data.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We did not propose to change the list of uncontrollable events or further define them, nor do we believe it is necessary to revise the references to disasters and emergencies to refer to a governmental declaration of that status or recovery or restoration periods. The events listed in the condition include acts of “military, civil, or regulatory authority” as well as natural or human-made disasters and other types of events or emergencies that might prompt a governmental authority to issue a declaration of disaster or emergency. However, consistent with the scope of the proposal, we emphasize that a key component of this condition is that an actor must demonstrate that a request for access, exchange, or use is infeasible because the uncontrollable event negatively impacts the actor's ability to fulfill the request.
                    </P>
                    <P>
                        <E T="03">Comment.</E>
                         A commenter recommended that we consider reporting flexibilities for this condition similar to those that other HHS programs put in place for declared emergencies, citing waivers issued in the context of public health emergencies for requirements of programs administered by the Centers for Medicare &amp; Medicaid Services (CMS).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We did not propose to create such a reporting system as suggested by the commenter nor is there currently a requirement for actors to routinely report to ONC which of their practices they believe they have structured to satisfy any information blocking exception(s). We thank the commenter for the suggestion.
                    </P>
                    <P>
                        <E T="03">Comment.</E>
                         A commenter noted the importance of minimizing administrative burden on health care providers, and specifically physicians delivering care in context of an emergency or disaster.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The commenter did not specify the types of administrative burden it was concerned about, but we suspect the concern is related to documenting compliance with the conditions of the Infeasibility Exception, including § 171.204(b). We emphasize that the 
                        <E T="03">uncontrollable events</E>
                         condition does not require specific documentation to be satisfied, and we did not propose specific documentation requirements for an 
                        <PRTPAGE P="1375"/>
                        actor to satisfy the 
                        <E T="03">uncontrollable events</E>
                         condition in paragraph (a)(2). We also did not propose to change the requirements of the 
                        <E T="03">responding to requests</E>
                         condition (§ 171.204(b)). Both conditions remain the same in this regard. The 
                        <E T="03">responding to requests</E>
                         condition (§ 171.204(b)) does not include specific documentation requirements, but does require the actor to provide the requestor, in writing, the reason(s) why the request is infeasible within ten business days of receipt of the request. An actor has flexibility in demonstrating how they met the 
                        <E T="03">uncontrollable events</E>
                         and the 
                        <E T="03">responding to requests</E>
                         conditions of the Infeasibility Exception.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter asked about an actor's burden of proof with respect to this exception.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As noted in the response to the comment above, we did not propose in the HTI-1 Proposed Rule specific documentation requirements for an actor to satisfy the 
                        <E T="03">uncontrollable events</E>
                         condition or the 
                        <E T="03">responding to requests</E>
                         condition of the Infeasibility Exception. In the ONC Cures Act Final Rule (85 FR 25821), we stated that an actor seeking an exception needs to meet all relevant conditions of the exception at all relevant times. For the Infeasibility Exception, an actor seeking to satisfy the exception would need to demonstrate it satisfied one of the conditions in § 171.204(a) and the condition in § 171.204(b). Further, as we noted in the HTI-1 Proposed Rule, the actor would need to produce evidence and ultimately prove that complying with the request for access, exchange, or use of EHI in the manner requested would have imposed a clearly unreasonable burden on the actor under the circumstances (88 FR 23865, citing 85 FR 25866). We also refer readers to the ONC Cures Act Final Rule (85 FR 25819) for additional discussion on establishing that an actor's practice(s) meet the conditions of an exception.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some comments we received discussed the 
                        <E T="03">responding to requests</E>
                         condition (§ 171.204(b)) as new or pending or in other ways that suggested some commenters may not have reviewed the full text of the existing Infeasibility Exception (§ 171.204) prior to commenting on the HTI-1 Proposed Rule.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank all commenters for their feedback. We appreciate the opportunity to remind actors, and any persons who may seek EHI access from actors, where and how to find all the information blocking exceptions, and to discuss a bit further here the Infeasibility Exception's structure and its requirements.
                    </P>
                    <P>First, we note that actors seeking to satisfy an exception, or other persons interested in when an exception applies, should review the exception's full regulatory text (found in the exception's section of 45 CFR part 171). In addition, the requirements and conditions of each exception set forth in subparts B, C, and D of 45 CFR part 171 should be read in context with the subpart's “availability and effect of exceptions” section (45 CFR 171.200, 45 CFR 171.300, and 45 CFR 171.400, respectively), as well as the general provisions in subpart A of 45 CFR part 171. The conditions under which each exception can be satisfied are specified in 45 CFR part 171. Where the conditions include any requirements the actor's practice must satisfy for an exception to apply, these requirements are included in that exception's section of 45 CFR part 171. For example, all of the conditions and requirements for the Infeasibility Exception to apply to an actor's practice of not fulfilling requested EHI access, exchange, or use due to the infeasibility of the request are specified in § 171.204. The general provisions in subpart A indicate the statutory basis and purpose of the information blocking regulations, the applicability of the regulations, and definitions of certain terms used in 45 CFR part 171.</P>
                    <P>
                        Specific to the Infeasibility Exception, the requirement that, for this exception to apply, the actor's practice must satisfy at least one condition in paragraph (a) and also satisfy the condition in paragraph (b) of § 171. 204 has been in place since the Infeasibility Exception (§ 171.204) was established in the ONC Cures Act Final Rule (85 FR 25869 and 85 FR 25958; 
                        <E T="03">see also</E>
                         85 FR 25867). Thus, as is the case for a practice meeting any of the conditions codified in § 171.204(a), an actor's practice consistent with the § 171.204(a)(1) 
                        <E T="03">uncontrollable events</E>
                         condition would also need to meet the requirements of § 171.204(b), the 
                        <E T="03">responding to requests</E>
                         condition, for that practice to fully satisfy the Infeasibility Exception.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters suggested that 10 business days may not be enough time for an actor severely impacted by a disaster to become aware of and respond to requests received around the time the disaster occurred, or that actors may need time to recover from an event before they are able to respond to requests for EHI. One of these commenters cited the potential for some events to be sufficiently disruptive and that the actor would lose the ability to access requests received before and during the disruption. The commenter noted that a 10-day response time may be unreasonable in the middle of a major hurricane involving power outage, facilities damage, and displacement of staff members key to processing requests. A comment suggested specific changes to the 
                        <E T="03">responding to requests</E>
                         condition so that an automated notice a system is down be considered as sufficient “notice” to satisfy the exception.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We did not propose in the HTI-1 Proposed Rule to change any aspect of the 
                        <E T="03">responding to requests</E>
                         condition (§ 171.204(b)) and decline to do so in this final rule. However, as it applies to actors' practices of not fulfilling requests that are infeasible because an uncontrollable event has, in fact, negatively impacted the actor's ability to fulfill access, exchange, or use of EHI, we welcome the opportunity to clarify that the 
                        <E T="03">responding to requests</E>
                         condition (§ 171.204(b)) does not focus on when the requestor sends or attempts to make the request. Rather, the 
                        <E T="03">responding to requests</E>
                         condition (§ 171.204(b)) specifies the “receipt of the request.” Satisfying the 
                        <E T="03">responding to requests</E>
                         condition, therefore, requires providing the reason for infeasibility in writing within ten business days of the actor 
                        <E T="03">receiving</E>
                         the request rather than counting ten business days from when a requestor may have sent or attempted to send the request.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter supported the Infeasibility Exception and asked that ONC consider further examples and definitions of extreme and uncontrollable circumstances to prevent abuse of the condition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support. We note that the finalized revision to § 171.204(a)(1) includes the following additional clause at its end: “. . . that in fact negatively impacts the actor's ability to fulfill the request.” This new additional clause makes it clear that in order for the actor's not fulfilling a request to satisfy the § 171.204(a)(1) 
                        <E T="03">uncontrollable events</E>
                         condition, the uncontrollable event must, in fact, have had an adverse impact on the actor's ability to fulfill a request for EHI access, exchange, or use. We believe the clarifying modification will help prevent abuse of the condition because it will enable actors to more confidently and accurately assess when and how the 
                        <E T="03">uncontrollable events</E>
                         condition could be satisfied, thus deterring actors from asserting they cannot fulfill a request merely because an uncontrollable event that did not negatively impact the actor's ability to fulfill the request had occurred.
                    </P>
                    <P>
                        <E T="03">Summary of finalized policy—uncontrollable events condition of the Infeasibility Exception (§ 171.204(a)(1)):</E>
                          
                        <PRTPAGE P="1376"/>
                        After consideration of comments received, we have finalized the revised 
                        <E T="03">uncontrollable events</E>
                         condition to the Infeasibility Exception with modifications to the proposed regulatory text. We have finalized our proposal to replace “due to” with “because of” in § 171.204(a). As discussed in response to comments, we have also added to the end of the text of § 171.204(a) the following: “that in fact negatively impacts the actor's ability to fulfill the request.” This addition is intended to improve the clarity with which the text conveys that to meet this specific condition of the Infeasibility Exception with respect to any request, an actor cannot simply assert that they cannot fulfill a request because an event consistent with § 171.204(a) occurred. To meet the condition, the actor must demonstrate that the uncontrollable event, in fact, negatively impacted the actor's inability to fulfill a request.
                    </P>
                    <HD SOURCE="HD3">b. Infeasibility Exception—Third Party Seeking Modification Use</HD>
                    <P>
                        In the HTI-1 Proposed Rule (88 FR 23865 through 23867), we proposed to renumber the Infeasibility Exception's (45 CFR 171.204) 
                        <E T="03">infeasible under the circumstances</E>
                         condition from paragraph (a)(3) to paragraph (a)(5) and to codify at (a)(3) a new condition 
                        <E T="03">third party seeking modification use.</E>
                         We proposed, as discussed in section IV.B.1.c below, another new condition that would be codified as paragraph (a)(4) of § 171.204. We received no comments expressing a particular view on the redesignation of 
                        <E T="03">infeasible under the circumstances</E>
                         condition as subparagraph (a)(5) and have, based on finalization of proposed new conditions in (a)(3) and (a)(4), finalized the redesignation of the 
                        <E T="03">infeasible under the circumstances</E>
                         condition as (a)(5).
                    </P>
                    <P>
                        We proposed that the § 171.204(a)(3) 
                        <E T="03">third party seeking modification use</E>
                         condition would apply in certain situations where the actor is asked to provide the ability for a third party (or its technology, such as an application) to modify EHI that is maintained by or for an entity that has deployed health information technology as defined in § 170.102 and maintains within or through use of that technology any instance(s) of any electronic health information as defined in § 171.102. As a reminder, to fully satisfy the exception in § 171.204, an actor's practice must meet one of the conditions in paragraph (a) of § 171.204 and the requirements in paragraph (b) of § 171.204 (“. . . the actor must, within ten business days of receipt of [a] request, provide to the requestor in writing the reason(s) why the request is infeasible”).
                    </P>
                    <P>
                        We proposed (88 FR 23865 through 23867) that the 
                        <E T="03">third party seeking modification use</E>
                         condition of the Infeasibility Exception would be limited to situations when “[t]he request is to enable use of EHI in order to modify EHI (including, but not limited to, creation and deletion functionality), provided the request is 
                        <E T="03">not</E>
                         from a health care provider requesting such use from an actor that is its business associate” (88 FR 23916, emphasis added).
                    </P>
                    <P>
                        In § 171.102, we define “use” for purposes of the information blocking definition to mean “the ability for electronic health information, once accessed or exchanged, to be understood and acted upon.” We stated in the ONC Cures Act Final Rule that “acted upon” within the final “use” definition “encompasses the ability to read, write, modify, manipulate, or apply the information. . . .” (85 FR 25806). Therefore, in § 171.204(a)(3), we proposed to use “
                        <E T="03">third party seeking modification use</E>
                        ” as a descriptive title for the new proposed condition of the Infeasibility Exception applicable to an actor's denial of requests from a third party for “modification use” of EHI. In particular, this new condition focuses on requests to modify EHI held by or for a health care provider and is not applicable to third-party requests for other activities that would fall within the § 171.102 definition of the broader term “use.” For example, the new 
                        <E T="03">third party seeking modification use</E>
                         condition would not apply to any request involving only the ability to read or apply the information, which are other activities in the broader definition of 
                        <E T="03">use</E>
                         we used in the ONC Cures Act Final Rule. The 
                        <E T="03">third party seeking modification use</E>
                         condition is also not applicable to any request for “access” or “exchange” (as these terms are defined in § 171.102) of EHI.
                    </P>
                    <P>
                        The information blocking definition (§ 171.103) refers to the “access, exchange, or use” of electronic health information, and each of these terms is defined for purposes of 45 CFR part 171 in § 171.102. In this portion of the preamble, as in the HTI-1 Proposed Rule (88 FR 23865), we use the term “modify” or “modification use” to describe the particular type of “use” covered by this new condition. We do so to avoid confusion between this “modification use” and the definition of the broader term 
                        <E T="03">use</E>
                         in § 171.102. It is important to note that the term “modification use” in the proposed and finalized § 171.204(a)(3) refers to a specific type of use within the § 171.102 definition of the term 
                        <E T="03">use</E>
                        .
                        <SU>249</SU>
                        <FTREF/>
                         Modification use focuses on actions on the EHI that change it in some way. Specifically, the condition focuses on requests to modify EHI held by or for a health care provider, but not to other types of “use,” such as the ability for EHI to be understood by a third party. The 
                        <E T="03">third party seeking modification use</E>
                         condition does not implicate, indicate, or imply any change to the definition of 
                        <E T="03">use</E>
                         in § 171.102 for any other purpose under 45 CFR part 171, or to any definition or other provision of the HIPAA Rules in 45 CFR parts 160 and 164. We recognize that HIPAA covered entities and business associates have an obligation under the HIPAA Privacy Rule to only disclose or use, in the sense of “use” as defined in 45 CFR 160.103, PHI as and when permitted or required under subpart E of 45 CFR part 164 or subpart C of 54 CFR part 1600 (see 45 CFR 164.502(a)). We have structured the information blocking regulations, including this finalized revision to the Infeasibility Exception, to accommodate that obligation.
                        <SU>250</SU>
                        <FTREF/>
                         We note that the 
                        <E T="03">third party seeking modification use</E>
                         condition does not imply or indicate any change to the HIPAA Rules (
                        <E T="03">see</E>
                         88 FR 23865).
                    </P>
                    <FTNT>
                        <P>
                            <SU>249</SU>
                             In § 171.102, we define “use” for purposes of the information blocking definition to mean “the ability for electronic health information, once accessed or exchanged, to be understood and acted upon.”
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>250</SU>
                             We discuss information blocking regulations' accommodation of HIPAA and other privacy laws in section 4.A, general comments.
                        </P>
                    </FTNT>
                    <P>
                        We proposed to add a definition of 
                        <E T="03">business associate</E>
                         to § 171.102 because we use the term in the 
                        <E T="03">third party seeking modification use</E>
                         condition. We proposed that the definition of 
                        <E T="03">business associate</E>
                         in § 171.102 would, by cross-reference to 45 CFR 160.103, be the same as the HIPAA Rules' definition of “business associate.” We emphasize that the § 171.204(a)(3) 
                        <E T="03">third party seeking modification use</E>
                         condition does not operate to change a business associate's rights or responsibilities under their business associate agreement (BAA) with any HIPAA covered entity. We also reiterate that the information blocking regulations do not require actors to violate BAAs or associated service level agreements. However, as we also previously explained in the ONC Cures Act Final Rule (85 FR 25812) and in information blocking FAQ28 (available at 
                        <E T="03">HealthIT.gov</E>
                         
                        <SU>251</SU>
                        <FTREF/>
                        ), terms or provisions of 
                        <PRTPAGE P="1377"/>
                        BAAs could constitute an interference (and thus could be information blocking) if used in a discriminatory manner by an actor to forbid or limit access, exchange, or use of EHI that otherwise would be a permitted disclosure under the HIPAA Privacy Rule. To determine whether there is information blocking, the actions and processes (
                        <E T="03">e.g.,</E>
                         negotiations) of the actors in reaching the BAA and associated service level agreements would likely need to be reviewed to determine whether there was any action taken by an actor that was likely to interfere with (“prevent, materially discourage, or otherwise inhibit”; § 171.102) the access, exchange, or use of EHI, and whether the actor had the requisite intent (85 FR 25812).
                    </P>
                    <FTNT>
                        <P>
                            <SU>251</SU>
                             IB.FAQ28.2.2021APR: “Do the information blocking regulations require actors to violate existing business associate agreements in order to not be considered information blockers?” (Available at 
                            <E T="03">
                                https://www.healthit.gov/faq/do-information-
                                <PRTPAGE/>
                                blocking-regulations-require-actors-violate-existing-business-associate.
                            </E>
                             Retrieved Sep 14, 2023.)
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Comments received on the proposed § 171.204(a)(3) 
                        <E T="03">third party seeking modification use</E>
                         condition were generally supportive. Comments supporting this proposal commended the proposal's alignment with the policy goals expressed in the HTI-1 Proposed Rule, including reducing the burden on actors to document each modification use request in the same way that an actor would need to document its actions for the 
                        <E T="03">infeasible under the circumstances</E>
                         condition of the Infeasibility Exception. Some commenters supportive of this proposal also expressed appreciation for the proposal's applicability to situations where an actor may be concerned about the accuracy or reliability of data that a third party would like to add to an individual's designated record set maintained by the actor. A few commenters also noted that the proposed condition would simplify the handling of certain requests for EHI. A few commenters expressed support for the proposal's exclusion of requests that come from health care providers to their business associates.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support expressed by many commenters. We have finalized the § 171.204(a)(3) 
                        <E T="03">third party seeking modification use</E>
                         condition with the minor modification of deleting the parenthetical “(including but not limited to creation and deletion functionality)” from the regulatory text in § 171.204(a)(3). This is done solely for readability purposes. The requests covered by this condition, as finalized, are to enable a third party EHI modification use functionality, including, but not limited to, creation and deletion functionality.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few of the commenters did not support the proposal. Some of these commenters expressed concern that the proposal could potentially inhibit care coordination by making it too easy for an actor holding EHI to simply refuse modification use requests from third parties who also furnish services to the same patient(s). Some of these commenters expressed concern that certain actors, such as health IT developers of certified health IT, may seek to misuse the proposal to restrict access to EHI in an overly broad manner.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for bringing to our attention their concerns about access, exchange, and use of EHI in support of care coordination. In developing our discrete proposal to provide further certainty to actors and now in finalizing this proposal, we have considered these concerns. In the HTI-1 Proposed Rule discussion of the reasons why this condition is not available to an actor when the actor is a business associate of a health care provider who is making the modification use request, we noted that there is often a level of trust and contractual protections between covered entities and business associates that removes certain concerns, such as security and data provenance, that led us to propose this new condition as structured (88 FR 23866). Many of these matters are addressed in business associate agreements, including security, as well as the permitted uses of the EHI (ePHI) that the covered entity grants the business associate. Further, the HIPAA Privacy and Security Rules place certain obligations on covered entities and their business associates that protect the privacy and security of EHI (and other PHI). For these reasons, we finalized this condition, as proposed, which permits actors to deny requests to modify EHI provided the request is not from a health care provider for which the actor is the business associate.
                    </P>
                    <P>
                        This condition was not proposed to apply, and as finalized does not apply, to an actor's practice of refusing to receive or process EHI via health information exchange or refusing to make EHI available for access, exchange, or use for permissible purposes. Where the manner or means of EHI use sought by a third party would not involve enabling a third party to modify (such as by adding to, creating, overwriting, editing, or deleting) EHI, then the condition does not apply even if the request is from someone other than a health care provider to whom the actor is a business associate. We also clarify that the 
                        <E T="03">third party seeking modification use</E>
                         condition applies only where a third party seeks modification use functionality for EHI within the records or systems maintained by the actor. This condition cannot be satisfied where a third party seeks access or exchange of EHI, even if the actor is certain that the requestor will or may make “modification use” of the EHI once it (or a copy of it) is in the requestor's possession, custody, or control. For example, the condition does not apply to situations where a health care provider, or their health IT developer chooses not to accept and process (such as through an EHR's receive and incorporate functions) EHI from a patient's health plan or prior health care provider or another of the patient's current health care providers. The condition also does not apply to read-only access (such as through API technology certified to any of the criteria in § 170.315(g)(7) through (10)), or to an actor's practice of refusing to make a patient's EHI available for access, exchange, or use by care coordination partners for permissible purposes. “Permissible purposes” is defined for purposes of the information blocking regulations in § 171.102.
                    </P>
                    <P>
                        Regarding commenters' concerns about entities potentially abusing the 
                        <E T="03">third party seeking modification use</E>
                         condition to restrict access, exchange, or use of EHI, the limited circumstances for which this condition applies, as described above and below, will mitigate any potential for abuse. This condition does not pose a problem for care coordination because it is very narrowly focused only on a particular manner of modification use of EHI (88 FR 23866) that the health care provider or the business associate would not have to enable, and it does not apply to a wide variety of manners by which health care providers routinely access, exchange, and use EHI for care coordination purposes. However, any abuse of this condition or any component of the information blocking regulations would be of concern to ONC, and we encourage anyone who believes they may have experienced or observed information blocking by any health care provider, health IT developer of certified health IT, or health information network or health information exchange to share their concerns with us through the Information Blocking Portal 
                        <SU>252</SU>
                        <FTREF/>
                         on ONC's website, 
                        <E T="03">HealthIT.gov</E>
                        .
                        <FTREF/>
                        <SU>253</SU>
                          
                        <PRTPAGE P="1378"/>
                        Information received by ONC through the Information Blocking Portal as well as the Health IT Feedback and Inquiry Portal 
                        <SU>254</SU>
                        <FTREF/>
                         also helps inform the development of resources we make publicly available on ONC's website, 
                        <E T="03">HealthIT.gov</E>
                        .
                    </P>
                    <FTNT>
                        <P>
                            <SU>252</SU>
                             URL 
                            <E T="03">https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/6</E>
                             (URL confirmed current and operational as of Sep 14, 2023).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>253</SU>
                             URL to Information Blocking topic section of 
                            <E T="03">HealthIT.gov: https://www.healthit.gov/topic/information-blocking.</E>
                             (URL confirmed current and operational as of Sep 14, 2023.)
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>254</SU>
                             URL 
                            <E T="03">https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2</E>
                             (URL confirmed current and operational as of Sep 14, 2023).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters requested that ONC provide further guidance on specific use cases where the 
                        <E T="03">third party seeking modification use</E>
                         condition could apply, including materials such as FAQs, scenario-based guidance, and examples of documenting use of the condition, including for behavioral health providers. One commenter recommended that documentation requirements for the condition be minimal.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We release educational resources on an ongoing basis. ONC-published resources can be found on 
                        <E T="03">HealthIT.gov</E>
                         and to date include for the HTI-1 rulemaking: recorded webinars (both general and tailored for particular topics and audiences), fact sheets, measurement spec sheets, blog posts, and a new website hub for links to various materials and educational resources. In addition to the examples we provided in the HTI-1 Proposed Rule and provide in this final rule describing the applicability of this condition, we will continue to provide resources such as infographics, fact sheets, webinars, and other forms of educational materials and outreach. Resources specific to the information blocking regulations in 45 CFR part 171, across this and other ONC rules, are available on 
                        <E T="03">HealthIT.gov.</E>
                         The short URL that redirects to the information blocking landing page is: 
                        <E T="03">healthit.gov/informationblocking.</E>
                    </P>
                    <P>
                        Regarding documentation requirements, we have not proposed or finalized a specific documentation requirement for the 
                        <E T="03">third party seeking modification use</E>
                         condition. In general, actors have flexibility to determine what documentation to create or keep in the event that they seek to claim an exception. However, as also discussed under the 
                        <E T="03">uncontrollable events</E>
                         condition above, an actor would need to demonstrate for each practice for which the Infeasibility Exception is sought on the basis of the 
                        <E T="03">third party seeking modification use</E>
                         condition (§ 171.204(a)(3)) that the condition was met at all relevant times and that the condition in § 171.204(b) was also met.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that the exceptions in subparts B and C of 45 CFR 171 are too complex for small health care providers, do not provide additional clarity, and that ONC should provide separate, simplified exceptions for health care providers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As we noted in the ONC Cures Act Final Rule, (85 FR 25819), we tailor information blocking exceptions and provide significant detail within each exception to clearly explain what an actor must do to meet each exception. For each exception, we typically propose and finalize conditions that can be consistently applied across all actors. However, there are conditions within certain exceptions that apply to one or a subset of actors, as applicable (85 FR 25819). As we stated in the ONC Cures Act Final Rule, the clearest and most equitable approach to the exceptions is to make all of the exceptions apply to all actors (85 FR 25819). Therefore, we decline the commenter's recommendation to provide “separate, simplified exceptions for health care providers.”
                    </P>
                    <P>We believe that our explanations of the exceptions, as included in the ONC Cures Act rulemaking and in the HTI-1 Proposed Rule and this final rule provide the necessary clarity for health care providers, including small health care providers, to understand and apply the exceptions. As discussed throughout this final rule, we also invest in educational outreach to interested parties, including small health care providers and associations that represent them, in an effort to further explain the exceptions through presentations and written resources such as fact sheets.</P>
                    <P>We also note that the exceptions are voluntary and offer an actor certainty that a practice that satisfies all of the relevant conditions of an exception will not be considered information blocking. Further, we reiterate that failure to meet an exception does not necessarily mean a practice meets the definition of information blocking. By satisfying an exception, an actor gains the assurance that the actor's practice does not constitute information blocking. An actor's practice that does not meet the conditions of an exception does not automatically constitute information blocking, as the practice must still meet all the elements of the information blocking definition to be considered information blocking, including that the practice is likely to interfere with the access, exchange, or use of EHI, and that the actor acted with the requisite intent (85 FR 25820).</P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters responded to our request for comment on whether the condition should be of limited duration, and specifically, whether we should consider proposing to eliminate the condition if, at some point in the future, health information technology is capable of supporting lawful third-party modification use of EHI by any party with no or minimal infeasibility or other concerns. The majority of comments on this subject stated either that the proposal should not have a sunset date, or that it would be premature to establish a sunset date at this time. Two commenters stated that the condition should or could be eliminated in the future if the future technology is capable of supporting the aforementioned modification use of EHI, with no or minimal infeasibility or other concerns.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their feedback. We agree that it would be premature to establish a sunset date for the condition because the appropriateness of eliminating the condition depends on the continued development of health IT's capability to support lawful third-party modification use of EHI by any party and with no or minimal infeasibility or other concerns. Because the pace of that continued health IT development is difficult to predict, we are not establishing a sunset date for § 171.204(a)(3) at this time. If advances in health IT capabilities or other changes in the interoperability and information sharing environment indicate to us that this condition should be modified or sunset, we would anticipate proposing such a change in a future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Three commenters expressed a concern that, as written, the condition would not apply to requests to “exchange” EHI by adding new EHI to a system through exchange from a third party. The commenters stated that ONC should add “exchange” of EHI to the condition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their feedback. The 
                        <E T="03">third party seeking modification use</E>
                         condition of the Infeasibility Exception is available to most actors to address situations where a third party's request is to modify EHI stored or maintained by an actor (88 FR 23866). The condition focuses on requests for a third party to have functionality to make modification use of EHI while, and as, it is held in the records or systems of the actor. We did not propose the condition to apply, and it cannot be met, where a third party is seeking to exchange EHI with the actor or to access a copy of EHI, even if the actor may know or reasonably suspect that the third party may modify (or have modified) EHI that is in records, applications, or systems maintained by the third party.
                        <PRTPAGE P="1379"/>
                    </P>
                    <P>In situations where an actor receives EHI via exchange from a third party, whether that EHI is reconciled and incorporated into the record (“added” to the record) is a determination for the health care provider and potentially its business associates. Any such exchange of EHI and subsequent determinations to reconcile and incorporate EHI into the record (or not) is not within the scope of the proposed condition. Such practices and scenarios may implicate the information blocking definition, but there may also be other conditions or exception that apply depending on the specific facts and circumstances.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters stated that the limitation to this condition is not broad enough, and that ONC should expand the limitation of this condition to also apply when the actor's customers are not HIPAA covered entities, or are not health care providers, but are maintaining EHI in systems licensed by an actor. Two commenters stated that the § 171.204(a)(3) 
                        <E T="03">third party seeking modification use</E>
                         condition should not apply in circumstances where the actor is a business associate or contractor of the organization that has licensed the interoperability elements or systems responsible for maintaining EHI. Along these lines, two other commenters expressed a concern that an actor, such as a health IT developer of certified health IT, that maintains EHI on behalf of an HIN/HIE could use this condition to deny an HIN/HIE's request, using third-party technology, for modification use of EHI maintained by the HIN/HIE. The commenters suggested that ONC clarify that the condition does not apply where a HIN/HIE requested modification use of EHI held by a health care provider or their health IT developer.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their feedback. We finalized the limitation to this condition to apply when the actor is a business associate of a health care provider making the modification use request, and we are not at this time expanding the limitation of the condition as some commenters suggested. As we noted in proposing this condition, there is often a level of trust and contractual protections between covered entities and business associates that removes certain concerns, such as security and data provenance, that led us to propose this new condition (88 FR 23866). We explained in the HTI-1 Proposed Rule discussion of the limitation of this condition that covered entities (health care providers) and their business associates (as permitted by their BAA) need to access and modify relevant EHI held by other business associates of those covered entities on a regular basis (88 FR 23866). Because our proposal focused on the obligations that the HIPAA Privacy and Security Rules place on covered entities and their business associates to protect the privacy and security of EHI (and other PHI), we decline to expand the limitation of the condition at this time.
                    </P>
                    <P>Regarding the commenters' concern about the application of the condition, we note that if the request for modification use is from the health care provider requesting such use from an actor that is the health care provider's business associate, the condition would not apply. Even if the actor who is a business associate of a health care provider could provide, or currently provides, items or services or engages in activities similar or identical to those the health care provider wants the third party to have modification use of EHI to accomplish, the condition does not apply when the actor is the business associate of the health care provider requesting modification use of EHI. Likewise, the finalized condition does not apply to an actor's denial of modification use by a third party where the actor is a subcontractor of any business associate to a health care provider, and the health care provider requests such use of EHI maintained by or on behalf of the health care provider. A “business associate” is a person or entity, other than a member of the workforce of a covered entity, who performs functions or activities on behalf of, or provides certain services to, a covered entity that involve access by the business associate to PHI (§ 171.102). A “business associate” is also a subcontractor that creates, receives, maintains, or transmits PHI on behalf of another business associate.</P>
                    <P>
                        For purposes of the provision “carving out” requests from a health care provider to an actor that is its business associate from application of § 171.204(a)(3), it does not matter whether the health care provider merely licenses or otherwise obtains from the actor use of interoperability elements that would be necessary to enable a third party's modification use of EHI that the health care provider maintains, or the health care provider contracts with the actor to maintain and manage on the health care provider's behalf. If the actor is a business associate of the health care provider and the provider requests modification use by a third party of EHI, then the condition does not apply to the actor's denial of that request. 
                        <SU>255</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>255</SU>
                             Whether other conditions in § 171.204(a) or another exception codified in subpart B or C of 45 CFR part 171 could be or have been satisfied in a particular situation would depend on the specific facts and circumstances of the case.
                        </P>
                    </FTNT>
                    <P>
                        For these reasons, and in consideration of these and all comments received on our discrete proposal, we finalized, as proposed, a condition that permits actors to deny requests to modify EHI provided the request is not from a health care provider for which it is the business associate. We have not at this time expanded the limitation to the condition as the commenters requested. However, we note that we may consider amending the 
                        <E T="03">third party seeking modification use</E>
                         condition or taking other appropriate steps in future rulemaking in response to changing market conditions, experience with the condition in practice, or other signals that suggest amending the condition may be appropriate.
                        <SU>256</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>256</SU>
                             Patterns described to us in claims or suggestions of possible information blocking submitted through the Report Information Blocking Portal illustrate just one example of such signals coming to our attention. (The Report Information Blocking Portal's URL as of Jul 28, 2023, is: 
                            <E T="03">https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/6</E>
                            ).
                        </P>
                    </FTNT>
                    <P>
                        As a reminder, the 
                        <E T="03">third party seeking modification use</E>
                         condition does not operate to change an actor's contractual obligations to their customers. When an actor engages in a practice to deny modification use of EHI under the 
                        <E T="03">third party seeking modification use</E>
                         condition, they may also wish to consider whether the practice violates any of their existing contractual obligations.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters raised issues that are out of scope for this proposal, including:
                    </P>
                    <P>• asking ONC to reiterate that actors cannot claim this exception to prevent requests from an individual or their personal representatives to amend the individual's PHI or record as permitted by the HIPAA Privacy Rule;</P>
                    <P>• a request for ONC to study what entities have access to health care providers' EHRs, why those entities may request to access or change authenticated documents or clinical notes, how health care providers evaluate the accuracy of data a third party wants to add to an individual's EHI, the potential benefits and harms of incorporating such data, and whether this condition would be possible in a future environment in which the Trusted Exchange Framework and Common Agreement (TEFCA) is actively exchanging data;</P>
                    <P>
                        • asking ONC to consider whether patients should be consulted before data from another health care provider is incorporated into their EHI;
                        <PRTPAGE P="1380"/>
                    </P>
                    <P>• asking ONC to consider what annotation mechanisms are or should be in place to create an audit trail for modifications to EHI;</P>
                    <P>• asking ONC to establish incentives for third-party applications to utilize best practices regarding maintaining the integrity and security of electronic health information;</P>
                    <P>• a request that the ten-business day timeline established in § 171.204(b) should be revised to be longer;</P>
                    <P>• a request to include in the certification criteria for health IT the functionality to alert an actor when a third party seeks modifications to EHI in the actor's system(s);</P>
                    <P>• recommending that ONC update certification criteria to better support health care providers' ability to use third-party apps maintained in certified health IT, utilizing existing APIs and support for user-created fields, while minimizing risks to data security and EHR performance;</P>
                    <P>• requesting examples of how providers should store information from a third party separate from the medical record, and requesting ONC work with health IT developers to implement a mechanism for providers to maintain data that has not been integrated into the medical record.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input and reiterate our continued commitment to supporting EHI sharing consistent with patient preferences and applicable law. Whether received as out-of-scope comments on a proposed rule or through informal channels, the feedback, and questions we receive, are appreciated and help to inform our development of information resources that we make publicly available on 
                        <E T="03">HealthIT.gov.</E>
                         Informal channels include, for example, the Health IT Feedback and Inquiry Portal 
                        <SU>257</SU>
                        <FTREF/>
                         that is available year-round and not tied to the comment period for a proposed rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>257</SU>
                             URL 
                            <E T="03">https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2</E>
                             (URL confirmed current and operational as of Sep 14, 2023).
                        </P>
                    </FTNT>
                    <P>
                        Regarding the relationship between the finalized § 171.204(a)(3) 
                        <E T="03">third party seeking modification use</E>
                         condition and the HIPAA Rules, we note again, as we did in the HTI-1 Proposed Rule, that the 
                        <E T="03">third party seeking modification use</E>
                         condition does not imply or indicate any change to the HIPAA Rules (
                        <E T="03">see</E>
                         88 FR 23865). Actors should note and should operate with awareness that a practice satisfying any information blocking exception in 45 CFR part 171 simply means that practice is not considered to be “information blocking” as defined in § 171.103. Any actor (as defined in 45 CFR 171.102) that is also subject to any provision(s) in 45 CFR parts 160, 162, or 164 must continue to comply with such provision(s) when and to the extent such provisions of the HIPAA Rules are applicable to the actor's conduct.
                    </P>
                    <HD SOURCE="HD3">Summary of Finalized Policy: Third Party Seeking Modification Use Condition</HD>
                    <P>As noted above and for the reasons stated above and in the HTI-1 Proposed Rule, we have finalized the condition as proposed with a non-substantive edit to simplify the regulation text by removing the parenthetical “(including, but not limited to, creation and deletion functionality).”</P>
                    <P>
                        We note that for purposes of this condition, an actor may choose to verify that the modification use request came from the health care provider themselves or accept the third party's representation of a request as coming from a health care provider. Any actor considering whether to potentially avail themselves of the certainty offered by this exception will have flexibility to structure their communications approaches and operating procedures for communicating with the health care provider of which the actor is a business associate, or with third parties representing themselves as business associates of such health care provider. This flexibility enables actors to operate and communicate efficiently while complying with the actor's obligations under the HIPAA Privacy Rule, other applicable law, and its binding agreements (including its BAAs) with the health care providers who choose to request modification use for a third party functionality either directly from the actor or through one of the health care provider's business associates. As discussed above under comments on documentation, an actor would need to demonstrate for each practice for which the Infeasibility Exception is sought on the basis of the 
                        <E T="03">third party seeking modification use</E>
                         condition (§ 171.204(a)(3)), that it met the 
                        <E T="03">third party seeking modification</E>
                         condition and also met the § 171.204(b) 
                        <E T="03">responding to requests condition</E>
                         at all relevant times.
                    </P>
                    <P>
                        As with every other condition in § 171.204(a), we note that the § 171.204(a)(3) 
                        <E T="03">third party seeking modification use</E>
                         condition stands alone. This means an actor's practice could meet it without needing to meet any other § 171.204(a) condition. It also means an actor's practice that fails to meet the § 171.204(a)(3) 
                        <E T="03">third party seeking modification use</E>
                         condition could nevertheless satisfy another of the conditions, such as the 
                        <E T="03">infeasible under the circumstances</E>
                         condition in § 171.204(a)(5).
                    </P>
                    <P>
                        We emphasize that other conditions within § 171.204(a) and all of the other exceptions would remain available for consideration by the actor as to their applicability to the situation and request where the finalized § 171.204(a)(3) 
                        <E T="03">third party seeking modification use</E>
                         condition of the Infeasibility Exception would not be available.
                    </P>
                    <HD SOURCE="HD3">c. Infeasibility Exception—Manner Exception Exhausted</HD>
                    <P>
                        In the HTI-1 Proposed Rule, we proposed to renumber the Infeasibility Exception's (45 CFR 171.204) “
                        <E T="03">infeasible under the circumstances”</E>
                         condition from paragraph (a)(3) to paragraph (a)(5) and to codify at (a)(4) a new “
                        <E T="03">manner exception exhausted”</E>
                         condition (88 FR 23867). We stated that the proposed 
                        <E T="03">manner exception exhausted</E>
                         condition would apply where an actor is still unable to fulfill a request for access, exchange, or use of EHI after having exhausted the exception in § 171.301 (which we have in this rule renamed Manner Exception, see Section IV.A.1), including offering all alternative manners in accordance with § 171.301(b), so long as the actor does not currently provide to a substantial number of individuals or entities similarly situated to the requestor the same requested access, exchange, or use of the requested EHI (88 FR 23867).
                    </P>
                    <P>
                        In the ONC Cures Act Final Rule (85 FR 25642), we finalized the Infeasibility Exception with modifications from the proposal (84 FR 7542 and 7603) to address concerns raised by commenters (
                        <E T="03">see</E>
                         85 FR 25866 through 25870). We finalized (85 FR 25858) three conditions that more specifically address situations where the Infeasibility Exception would be appropriately used. One of the conditions we finalized, 
                        <E T="03">infeasible under the circumstances,</E>
                         requires the actor to demonstrate, through a contemporaneous written record or other documentation, its consideration, in a consistent and non-discriminatory manner, of certain factors that led to its determination that complying with the request would be infeasible under the circumstances. The Infeasibility Exception (§ 171.204), as finalized in the ONC Cures Act Final Rule, provides assurance to an actor that if it meets applicable conditions of the exception at all relevant times, its practice will not be considered information blocking.
                    </P>
                    <P>
                        Also, in the ONC Cures Act Final Rule, we finalized the “Content and Manner Exception” (now the Manner Exception) (45 CFR 171.301). Under § 171.301, for the Manner Exception to apply, an actor must fulfill a request for 
                        <PRTPAGE P="1381"/>
                        access, exchange, or use of EHI in any manner requested, unless the actor is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request (45 CFR 171.301(b)(1)(i), as originally codified). If an actor and requestor reach agreeable terms and the actor fulfills a request described in the manner condition in any manner requested: (1) Any fees charged by the actor in relation to its response are not required to satisfy the Fees Exception in § 171.302; and (2) any license of interoperability elements granted by the actor in relation to fulfilling the request is not required to satisfy the Licensing Exception in § 171.303 (45 CFR 171.301(b)(1)(ii), as originally codified) (85 FR 25877).
                    </P>
                    <P>Section 171.301(b)(2) (original codification, redesignated in this final rule as § 171.301(b)) provides for fulfilling a request to access, exchange, or use EHI in a manner other than the manner requested. If an actor does not fulfill a request in any manner requested because it is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request, the actor must fulfill the request in an alternative manner agreed upon with the requestor consistent with § 171.301(b)(2) (original codification, now redesignated § 171.301(b)) in order to satisfy the exception (85 FR 25877). The Manner Exception offers certainty that an actor's practices that fully satisfy the Manner Exception's conditions will not be considered information blocking and is meant to incentivize offering an alternative manner (with priority to interoperable manners based on HHS-adopted and available open standards) when the actor is unable to fulfill access, exchange, or use of the requested EHI in the manner initially requested.</P>
                    <P>
                        As discussed in the HTI-1 Proposed Rule, actors expressed uncertainty to ONC as to whether they have satisfied the 
                        <E T="03">infeasible under the circumstances</E>
                         condition in instances where they contended that fulfilling a request for access, exchange, or use of EHI would be infeasible (85 FR 23867). Under the Infeasibility Exception, the 
                        <E T="03">infeasible under the circumstances</E>
                         condition requires the actor to demonstrate that complying with the request is infeasible when considering, among other things, the financial and technical resources available to the actor and why the actor was unable to provide access, exchange, or use of EHI consistent with the Manner Exception. Specifically, actors have expressed concern about circumstances where the actor's inability to satisfy the Manner Exception's conditions rests solely on the requestor refusing to accept access, exchange, or use in 
                        <E T="03">any</E>
                         manner consistent with § 171.301, and fulfilling the request in the manner requested would require substantial technical or financial resources (or both) in the view of the actor, including significant opportunity costs. We have observed this being more of a concern for actors with significant skills and other resources for developing unique technical solutions or new technological capabilities (
                        <E T="03">e.g.,</E>
                         EHR developers or HIN/HIEs) than for actors with few to no such resources (
                        <E T="03">e.g.,</E>
                         small clinician office practices or safety net clinics), because, as noted, the 
                        <E T="03">infeasible under the circumstances</E>
                         condition of the Infeasibility Exception (§ 171.204(a)(5); previously § 171.204(a)(3)) requires actors to demonstrate their consideration of the financial and technical resources available to them, as well as why the actor was unable to provide access, exchange, or use of EHI consistent with § 171.301.
                    </P>
                    <P>
                        Among those actors with substantial skills and other resources to develop new, unique or unusual manners of supporting access, exchange, or use of EHI, we see actors who appear to be experiencing a problematic level of uncertainty about whether they will be engaging in information blocking if they decline demands from requestors for non-standard or non-scalable solutions that they do not currently support 
                        <E T="03">even after</E>
                         they have offered to provide access, exchange, or use of EHI in the same manner(s) the actor makes generally available to its customers or affiliates, 
                        <E T="03">and</E>
                         through standards-based manners, consistent with § 171.301—including offering terms for such manners that are consistent with the Fees (§ 171.302) and Licensing (§ 171.303) Exceptions. We anticipate that this uncertainty will lead actors who, again, have already exhausted the Manner Exception (§ 171.301), to divert their development capacity to fulfilling requested manners of access, exchange, or use of EHI that they 
                        <E T="03">could</E>
                         invent to meet the demands of a requestor determined to accept only the original manner they specified and who are unwilling or unable to agree to terms consistent with the Fees (§ 171.302) and Licensing (§ 171.303) Exceptions for their requested manner or any alternative manner consistent with the Manner Exception (§ 171.301) (88 FR 23868).
                    </P>
                    <P>We stated in the HTI-1 Proposed Rule (88 FR 23868) that this new condition is necessary to ensure actors reasonably allocate resources toward interoperable, standards-based manners rather than allowing requestors, who, for whatever reason, do not build their products for compatibility with open consensus standards or other industry standards to attempt to force use of non-standard or non-scalable solutions by simply refusing to accept access, exchange, or use of EHI in any other manner. This diversion of resources away from standards-based and scalable manners of exchange detracts from, instead of supporting, achievement of key policy goals such as increased interoperability and innovation in use of open consensus standards to achieve secure, seamless exchange. Where novel approaches to system interfaces or other aspects of access, exchange, or use of EHI represent improvements over other available approaches, we anticipate these approaches will not need to be forced upon the industry but will instead find a natural foothold and diffuse according to a normal innovation curve.</P>
                    <P>
                        Therefore, to reduce confusion and provide more certainty to actors, we proposed and have finalized at § 171.204(a)(4) a new condition in the Infeasibility Exception, the 
                        <E T="03">manner exception exhausted</E>
                         condition. Actors will be able to satisfy this exception when they have “exhausted” the 
                        <E T="03">manner requested</E>
                         condition and 
                        <E T="03">alternative manner</E>
                         condition of the Manner Exception and meet the other requirements of the new condition. If an actor either technically cannot provide the access, exchange, or use of EHI in the manner requested, or the actor and requestor cannot reach agreeable terms on the manner requested, then the actor must attempt to fulfill the request using the alternative manners in § 171.301(b) (85 FR 25877) (previously § 171.301(b)(2)(i)). Under the Manner Exception, for any alternative manner, the requestor must either specify the manner they would accept (§ 171.301(b)(2)(i)(A) and (B)) or specifically agree with the machine-readable format that they would accept (§ 171.301(b)(2)(i)(C)). In situations where an actor offers the alternative manners and the requestor does not specify or agree to receive the EHI via the offered alternative manners (as may be the case if the requestor does not want to receive the EHI in such a manner or cannot receive the EHI in such a manner), an actor may now seek to satisfy the new finalized 
                        <E T="03">manner exception exhausted</E>
                         condition of the Infeasibility Exception.
                    </P>
                    <P>
                        Previously, an actor who offered all the alternative manners would likely look to the 
                        <E T="03">infeasible under the circumstances</E>
                         condition of the Infeasibility Exception, which requires actors to demonstrate that complying with the request is infeasible when 
                        <PRTPAGE P="1382"/>
                        considering many factors, including the cost to the actor of complying with the request in the manner requested and the financial and technical resources available to the actor. The newly finalized 
                        <E T="03">manner exception exhausted</E>
                         provides actors the option of satisfying the Infeasibility Exception without needing to assess whether they 
                        <E T="03">could</E>
                         meet the requestor's particularized demands regarding the manner and/or terms in which they want to obtain access, exchange, or use of the requested EHI.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Most commenters were supportive of ONC's proposal to add the 
                        <E T="03">manner exception exhausted</E>
                         condition to the Infeasibility Exception. Commenters stated that it would reduce burden and allow actors to focus on innovation. Many commenters appreciated that the condition encourages use of standards-based mechanisms, and that it removes the uncertainty that could come about if it is technically infeasible for an actor to fulfill a request or when the actor has offered the alternative manners, but the requestor has not specified or agreed, as applicable, to access, exchange, or use of the EHI in any of those manners. Many commenters also appreciated ONC's acknowledgment that interoperable, standards-based exchange should be favored over expensive, resource-intensive, one-off solutions. Other commenters expressed appreciation that the condition allows health IT developers of certified health IT and other actors the opportunity to reach agreement on market-based terms and pricing to protect investments, while still promoting interoperability. A few commenters also expressed appreciation that the condition can be met without the actor needing to demonstrate they considered the resources available to the actor, and that exchanging entities will be protected from costly technical changes or solutions made solely to avoid claims of information blocking.
                    </P>
                    <P>Alternately, a few commenters expressed general disagreement with the proposed condition. One commenter expressed concerns that the condition could be interpreted to allow actors to remain in exchange patterns that do not expand interoperability across a range of requestors and use cases. Another commenter noted that atypical requests may be necessary to achieve a particular use of EHI that is not adequately supported by existing standards.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their thoughtful feedback. Upon consideration of all comments received related to this proposal, we have finalized the condition as proposed with two modifications discussed below. We agree that the 
                        <E T="03">manner exception exhausted</E>
                         condition prioritizes interoperability and encourages efficiency by applying the Infeasibility Exception under circumstances where the actor cannot meet, or cannot be certain that they have met, the 
                        <E T="03">infeasible under the circumstances</E>
                         condition. We recognize that custom, one-off solutions can be costly and inhibit investment in innovative, scalable approaches to interoperability and exchange. We also recognize that atypical requests may be necessary to achieve a particular use of EHI and note that nothing in the information blocking regulations would prevent a requestor and actor from coming to an agreement to achieve innovative solutions to interoperability challenges or atypical use cases. To this point, we previously established the 
                        <E T="03">manner requested</E>
                         condition of the Manner Exception, now codified in § 171.301(a), which permits actors and requestors to come to terms on access, exchange, and use of EHI without such terms necessarily satisfying the § 171.302 Fees Exception or § 171.303 Licensing Exception.
                    </P>
                    <P>
                        In response to concerns that this may allow actors to remain in exchange patterns that do not expand interoperability, we note that satisfying the finalized 
                        <E T="03">manner exception exhausted</E>
                         condition of the Infeasibility Exception requires the actor to offer a standards-based method of exchange, either through certified health IT or using technology and transport standards published by the federal government or a standards developing organization accredited by the American National Standards Institute (ANSI). Both methods would support interoperability, and the use of certified health IT incrementally expands interoperability through certification to new and revised certification criteria that include new and updated standards and capabilities.
                    </P>
                    <HD SOURCE="HD3">How many alternative manners are required to satisfy the condition?</HD>
                    <P>
                        In the HTI-1 Proposed Rule, we stated that it is important that the Manner Exception not be considered exhausted if the actor offers only one alternative manner, or only the least-interoperable “alternative machine-readable format” now codified in § 171.301(b)(1)(iii) (88 FR 23869). Therefore, we proposed a second factor requiring actors to have offered all three alternative manners in accordance with § 171.301(b) (88 FR 23869). We requested comments on how many of the alternative manners an actor should be required to offer in order to satisfy the proposed 
                        <E T="03">manner exception exhausted</E>
                         condition of the Infeasibility Exception: one, two, or all three alternative manners.
                    </P>
                    <P>
                        As explained below, we have finalized the 
                        <E T="03">manner exception exhausted</E>
                         condition of the Infeasibility Exception with a requirement that an actor offer two alternative manners, at least one of which must be either the alternative manner in § 171.301(b)(1)(i) or (b)(1)(ii). These alternative manners are, respectively, “[u]sing technology certified to standard(s) adopted in part 170 that is specified by the requestor” (in other words, via health IT certified under the ONC Health IT Certification Program, 45 CFR part 170) or, “[u]sing content and transport standards specified by the requestor and published by: (A) the Federal Government; or (B) a standards development organization accredited by the American National Standards Institute” (45 CFR 171.301(b)(1)). An actor may offer both of these alternative manners to satisfy this particular factor of the 
                        <E T="03">manner exception exhausted</E>
                         condition, or only one of these two 
                        <E T="03">and</E>
                         the manner specified in § 171.301(b)(1)(iii), which is “[u]sing an alternative machine-readable format, including the means to interpret the electronic health information, agreed upon with the requestor.” If the actor offers the EHI in at least two manners including one of either (b)(1)(i) or (b)(1)(ii), then this factor of the finalized 
                        <E T="03">manner exception exhausted</E>
                         condition is satisfied.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Responses to our request for comment on how many alternative manners an actor should be required to offer before this condition would be available reflected a broad range of perspectives. Many commenters said two alternative manners should be enough. Other commenters said just one, and a couple of commenters suggested requiring actors to exhaust all of the actor's 
                        <E T="03">own</E>
                         manners of exchange prior to making use of the condition. Another commenter requested that an actor be required to demonstrate that they have inventoried all of the information sharing tools available that could be offered as an alternative manner and require the actor to have made those available to the requestor before they can satisfy the condition. One commenter asked for a specific carve-out for health care providers that would only require them to offer access, exchange, or use in the manners supported by their certified health IT or any other manner that requires minimal effort. Another commenter suggested a specific carve-out for health care providers who do not use certified health IT, stating that it should be 
                        <PRTPAGE P="1383"/>
                        enough for such actors to offer access, exchange, and use only in a machine-readable manner. One commenter suggested that ONC require actors to offer a minimum of two manners for USCDI data elements, and only one alternative manner for any EHI beyond USCDI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         After reviewing all comments, in § 171.204(a)(4)(ii), we have finalized the regulatory text so that the 
                        <E T="03">manner exception exhausted</E>
                         condition can be satisfied when an actor (who was unable to fulfill a request for access, exchange, or use of EHI because they could not reach an agreement with a requestor or were technically unable to fulfill the request in the manner requested) offered the requestor at least two alternative manners, one of which must use either technology certified to standard(s) adopted in part 170 that is specified by the requestor (§ 171.301(b)(1)(i)) or published content and transport standards consistent with § 171.301(b)(1)(ii).
                    </P>
                    <P>
                        By requiring actors to offer at least one of the first two alternative manners (as listed in § 171.301(b)(1)(i)-(iii)), we are balancing the interest of the actor in achieving certainty that the practice will fulfill the new condition, while also ensuring that interoperable, standards-based exchange remains favored over other methods of exchange. We believe that requiring all three alternative manners, as originally proposed, would place an unequal burden on actors who are not required by other government regulations or incentivized by any public or private program to use certified health IT. We believe that requiring two alternative manners, one of which must be more interoperable than is typically the case with a machine-readable format (
                        <E T="03">i.e.,</E>
                         § 171.301(b)(1)(iii)), ensures that the condition will not have the undesirable effect of dampening actors' or requestors' enthusiasm for adopting and advancing standards-based interoperability.
                    </P>
                    <P>
                        The finalized requirement for the actor to have offered at least two alternative manners also balances the interests of those commenters who requested the condition be satisfied with just one alternative manner and those who wanted all three alternative manners. While nothing would stop an actor from offering a requestor all available manners at its disposal, we believe making that a requirement to satisfy the 
                        <E T="03">manner exception exhausted</E>
                         condition would render the condition impractical for many actors to satisfy and defeat at least a portion of our purpose in proposing it: to offer actors a simpler option for certainty than was already available in the 
                        <E T="03">infeasible under the circumstances</E>
                         condition. We also note that an actor could respond to a request by providing as much of the EHI as possible via any manner requested or an alternative manner, and still make use of the 
                        <E T="03">infeasible under the circumstances</E>
                         condition for any other EHI that they are technically unable to offer via an alternative manner, so long as the practice satisfies all the requirements of that condition (now § 171.204(a)(5)). As a reminder, to meet the Infeasibility Exception as a whole, actors will still, regardless of the condition(s) satisfied in paragraph (a) in § 171.204, also need to satisfy the condition in paragraph (b): 
                        <E T="03">responding to requests.</E>
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters expressed confusion over what exactly is an “alternative manner.” One commenter stated that, taken literally, “all alternative manners” would force an actor to offer tens or hundreds of possible technical solutions.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments and the opportunity to address the confusion. When referring to “alternative manners” we do not mean all possible manners of exchange other than the manner requested. Rather, we specifically mean only manners that would be consistent with subparagraph (i), (ii), or (iii) of § 171.301(b)(1). Offering as few as one option per category is sufficient to satisfy either paragraph (b)(1) of the 
                        <E T="03">alternative manner</E>
                         condition of the Manner Exception (§ 171.301) or the “at least two alternative manners” requirement finalized as part of this 
                        <E T="03">manner exception exhausted</E>
                         condition (subparagraph (a)(4)) of the Infeasibility Exception (§ 171.204).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter asked that ONC clarify that responding actors are responsible to exchange EHI for the purpose and in the manner requested, if they are able to do so, even if they are not accustomed to utilizing the requested transaction pattern.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the opportunity to clarify. The commenter is incorrect. An actor may satisfy any of the exceptions to the information blocking definition in order to have certainty that their practice is not information blocking. Under the 
                        <E T="03">manner requested</E>
                         condition (now § 171. 301(a)) of the Manner Exception, an actor responding to a request to exchange EHI for a certain purpose and in a certain manner must only do so if they are technically able to and reach an agreement with the requestor. If they are not technically able to do so, or cannot reach agreement with the requestor, then an actor seeking certainty that their practice would not be information blocking would need to either satisfy the other conditions of the Manner Exception or satisfy a different exception to the information blocking definition. The exceptions to the information blocking definition are voluntary and offer an actor certainty that a practice that satisfies all of the applicable requirements and conditions of an exception at all relevant times will not be considered information blocking.
                    </P>
                    <P>
                        The 
                        <E T="03">manner exception exhausted</E>
                         condition is 
                        <E T="03">not</E>
                         available when exchange is technically feasible and can be accomplished consistent with the Manner Exception, whether because the parties have agreed to terms for fulfillment in the manner requested (
                        <E T="03">manner requested</E>
                         condition) or because the requestor has specified and/or agreed to accept access, exchange or use consistent with the Manner Exception's 
                        <E T="03">alternative manner</E>
                         condition—even if the actor is not accustomed to utilizing the requested manner to support access, exchange, or use of the EHI the requestor seeks, in general or for the same or similar permissible purpose a particular requestor seeks EHI access, exchange, or use. In other words, this condition would 
                        <E T="03">not</E>
                         be available if a responding actor is able to exchange EHI in the manner requested, and the parties have either reached agreeable terms for such access, exchange, or use; or the requestor has specified and/or agreed to accept such access, exchange or use in an alternative manner consistent with the Manner Exception. We emphasize that nothing about the 
                        <E T="03">manner exception exhausted</E>
                         condition prevents an actor from providing a requestor with a custom build for access, exchange, or use of EHI. Rather, this condition has been adopted to alleviate actor uncertainty as to whether they must provide the custom build or otherwise be considered to have engaged in information blocking.
                    </P>
                    <P>
                        We note that in cases where a requestor seeks a specific alternative manner of access, exchange, or use consistent with § 171.301(b)(1), and the actor declines to offer that manner (even if the actor is able to accommodate the requested alternative manner) and instead offers a different alternative manner, the OIG may consider this as a factor in determining whether information blocking has occurred, particularly if the requestor is unable to access, exchange or use the EHI in the offered alternative manner. For example, if a requestor specifies a FHIR-based API as its preferred alternative manner of access, exchange, or use, and the actor is capable of doing so, then the 
                        <PRTPAGE P="1384"/>
                        actor should prioritize fulfilling the request via FHIR, even if the actor is also capable of fulfilling the request via another alternative manner, such as C-CDA document exchange. ONC has consistently maintained this policy approach because it best ensures that EHI is made available where and when it is needed (for further discussion, 
                        <E T="03">see</E>
                         the ONC Cures Act Final Rule at 85 FR 25877).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter stated that if an actor is unable to reach agreeable terms with a requestor for access, exchange, or use of EHI, or is technically unable to fulfill a request in the manner requested, and then proceeds to offer one or more alternative manners and the requestor is still not satisfied, then the burden should shift to the requestor to demonstrate and justify why the alternatives proposed by the actor are infeasible or otherwise insufficient to meet their needs. Further, the commenter stated that the actor who received the request should have a duty to respond to the requestor only after receiving a written statement setting forth such justification.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment. We decline to adopt this suggestion, however, because we find it inappropriate to entirely shift the burden to the requestor. Our information blocking regulatory scheme, consistent with the statutory information blocking definition, supports policy goals of discouraging interference with EHI access, exchange, or use, and encouraging routine, interoperable EHI sharing for permissible purposes consistent with patients' privacy preferences. Although we recognize there is substantial variation in actors' and requestors' circumstances, we do not believe our policy goals would be well served by identifying as “reasonable and necessary” any actor's practice of demanding a requestor to justify to the actor their need or preference for a different manner of EHI access, exchange, or use than the actor prefers to offer (42 U.S.C. 300jj-52). A key aim of our information blocking regulatory scheme is to discourage information blocking by actors and make it easier for requestors to obtain, for any permissible purpose, EHI access, exchange, or use in a manner that meets the requestor's needs. The condition, as finalized, requires the actor to offer only two alternative manners, at least one of which is standards-based. It, therefore, allows the actor enough flexibility to avoid developing one-off, unique, custom solutions unless the actor wants to do so. The actor who satisfies the § 171.301 Manner Exception by meeting the 
                        <E T="03">manner requested</E>
                         condition would not need to also satisfy any condition in the § 171.204 Infeasibility Exception, assuming all requested EHI was provided consistent with the Manner Exception. The § 171.301(a) 
                        <E T="03">manner requested</E>
                         condition also, we reiterate, allows the actor and requestor to come to any mutually agreeable terms, thereby allowing for those requestors, able and willing to do so, to satisfy any financial incentive the actor would require to develop any requested manner, however unique or one-off, the requestor might want developed.
                    </P>
                    <P>
                        <E T="03">Comment.</E>
                         At least one commenter stated that this condition should still be available in circumstances where the only applicable option is a “machine-readable format,” in other words, § 171.301(b)(1)(iii).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment. As stated above, we have finalized this condition with a requirement that the actor offer at least two “alternative manners” from § 171.301(b)(1)(i)-(iii), one of which must be either the alternative manner in § 171.301(b)(1)(i) or (b)(1)(ii). Because a machine-readable format is the option of last resort, and the least-interoperable of all the alternative manners, we believe that allowing a requestor to offer only a machine-readable format would be at odds with the purpose of the new condition. We note that an actor who is able only to offer access, exchange, or use of EHI in a manner consistent with § 171.301(b)(1)(iii) would not be able to make use of this condition but could still conform its practice to another applicable condition (for example, the 
                        <E T="03">infeasible under the circumstances</E>
                         condition of the Infeasibility Exception) in order to have certainty that the practice would not constitute information blocking. Moreover, even a practice that does not satisfy any exception does not automatically constitute information blocking. The facts and circumstances of any situation or allegation would need to be evaluated, and whether the practice constitutes information blocking depends on the unique facts and circumstances of the practice.
                    </P>
                    <HD SOURCE="HD3">What counts as a “substantial number”?</HD>
                    <P>
                        We proposed, as the third factor of the 
                        <E T="03">manner exception exhausted</E>
                         condition, that the condition would be available only if “the actor does not provide the same access, exchange, or use of the requested electronic health information to a 
                        <E T="03">substantial number</E>
                         of individuals or entities that are similarly situated to the requestor.” In the HTI-1 Proposed Rule, we stated that “this factor as a whole serves a similar function to the § 171.204(a)(5) (originally codified in § 171.204(a)(3)) 
                        <E T="03">infeasible under the circumstances</E>
                         condition's factor considering whether the actor's practice is non-discriminatory, and the actor provides the same access, exchange, or use of electronic health information to its companies or to its customers, suppliers, partners, and other persons with whom it has a business relationship” (88 FR 23870). We noted that the intent of the third factor is to provide a basic assurance that actors would not be able to misuse the § 171.204(a)(4) 
                        <E T="03">manner exception exhausted</E>
                         condition to avoid supplying some particular requestor(s) with manner(s) of access, exchange, or use of the requested EHI that would be more accurately characterized as generally available than as new, unique, or unusual (88 FR 23870). Given that intent, we stated that the proposed regulatory language of subparagraph (iii) of the condition “while on its face may seem indefinite and 
                        <E T="03">is</E>
                         designed to address 
                        <E T="03">any</E>
                         potential request, is intended to ensure that the actor offers any requestor . . . the same access the actor provides to a substantial number of its customers . . .” (88 FR 23870). We requested comment on whether we should further define “substantial number” for purposes of this condition.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters responded to this proposed provision of the 
                        <E T="03">manner exception exhausted</E>
                         condition. Some suggested we keep the “substantial number” flexible and not further define it. One commenter suggested that we set a certain percentage such that an actor providing the same access, exchange, or use to a percentage of its customers would not be able to deny the requestor the same access, exchange, or use and still make use of this condition. Another commenter suggested that even one customer should be enough, because just one customer can constitute the bulk of an actor's business, or one customer can request a more innovative manner that should be made available to all requestors without the use of the condition to cover an actor's practice of denying such access, exchange, or use. One requestor stated that “substantial number” was an inappropriate metric for the factor, because “generally available” or other terms indicating the state of a product or service are not typically dependent on the number of users but rather the actor's ability to service any requests for such functionality. The same commenter noted that lack of adoption of a given feature may occur for many reasons that have no bearing on the usefulness of the 
                        <PRTPAGE P="1385"/>
                        feature, and therefore any functionality that is considered usable by customers should be considered normal and customary practice, even if only one customer uses it. The commenter expressed concerns that the adoption level could be kept artificially low by telling initial requestors “no,” thereby preventing the particular feature from being considered “generally available” or similar. Another commenter said that if a functionality is considered usable by customers, then having any customer use it should be considered normal and customary practice, and it shouldn't matter if, for a time, they are the only customer using that feature.
                    </P>
                    <P>Other commenters supported keeping the term “substantial number” without further specifying a specific number. These commenters stated that such an approach allows the right level of flexibility, with one commenter remarking that it permits actors to consider the specific means of access, exchange, or use of EHI contemplated by each request and the specific use case for which the request is made. Another commenter supported ONC's reasoning for not using a fixed number to define “substantial number,” referring to the reasoning laid out in the HTI-1 Proposed Rule (which is also discussed below).</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their feedback and input. We have finalized in § 171.204(a)(4)(iii) the term “substantial number” without further specificity. We believe this allows the appropriate amount of flexibility for all actor types, who may have very different numbers of requestors, to satisfy this condition based on what number of requestors is substantial for that actor. As we stated in the HTI-1 Proposed Rule, using “substantial number” rather than a specific number is important to recognize variation in actors' operational contexts, including their organizational sizes. What may be a trivial number to a large health IT developer of certified health IT might be an important or consequential (“substantial”) number for a small HIN/HIE (88 FR 23870). In addition, while we believe that calculating a percentage may be helpful to an actor in determining whether it provides a substantial number of customers the requested access, we do not believe establishing a specific percentage would be helpful given the wide variation in the number of customers an actor may have. For example, an actor with a large number of customers who provides the access to dozens of customers might only be providing such access to ten percent of its customers. Further, we did not propose such an approach for consideration.
                    </P>
                    <P>
                        In response to commenters who suggested we use a specific number, such as one, we note that in some cases, even one customer could be a substantial number, if, for example, it represents a large portion of the actor's deployments or is considered “generally available” as part of an actor's line of business (
                        <E T="03">see</E>
                         below and 88 FR 23870 for a discussion of “generally available/general availability”). Simply stating one, or more than one, could be overly broad and end up capturing one-off manners, custom builds, or highly customized deployments that are not easily replicable for another requestor without abandoning open consensus standards or interoperable manners. In other words, we believe that “substantial number” is flexible enough to include as few as one customer, when appropriate, and as many as all of a given actor's customers. Further, providing a fixed number could be considered arbitrary.
                    </P>
                    <P>
                        In response to commenters who noted that if a functionality is used by even one customer, it should be offered even if, for a time, there is only one customer using it. We agree that there may be instances where just one customer is using a particular functionality that is suitable and scalable for use by requestors beyond that one customer. However, in other instances, a functionality may be in use by only one customer because it is a custom build that would be difficult to replicate or scale, or because it is an obsolete product that this one customer continues to find sufficient for their needs. We, therefore, believe setting the standard that an actor cannot meet the 
                        <E T="03">manner exception exhausted</E>
                         condition if any one customer is using a requested build could too often prevent the condition from applying when a requestor seeks a manner that is not generally available or interoperable. Moreover, in the free market, especially useful features would be expected to attract the notice of developers and their customers, with the best features eventually being adopted by more than one customer.
                    </P>
                    <P>Finally, in the HTI-1 Proposed Rule preamble, we stated that we chose to structure the § 171.204(a)(4)(iii) factor to align with the concept of whether the manner requested, including involved interoperability elements, is in a stage of development or overall lifecycle that would roughly approximate the “general availability” phase of the software release lifecycle, or a conceptually analogous phase for non-software interoperability elements (88 FR 23870). However, we recognize that not all actors are developers, and we intend this condition of the Infeasibility Exception to be available for all types of § 171.102 actors. As we stated in the HTI-1 Proposed Rule, health care providers, for example, do not typically develop software for the market and, in our observation, are likely to characterize components of their health IT systems in more operational terms—such as what has “gone live” in their particular implementation—than in software release lifecycle terms. We believe avoiding the specific lifecycle term also avoids potential for misunderstandings among actors and requestors, or for gamesmanship on the part of actors, around when different actors consider a particular interoperability element to enter or to be withdrawn from “general availability” as the term is widely used in the software sector. We finalize “substantial number” with the same analysis and guidance found in the HTI-1 Proposed Rule (see 88 FR 23870 through 23871).</P>
                    <HD SOURCE="HD3">What does “provide” mean in this context?</HD>
                    <P>
                        <E T="03">Comments.</E>
                         We received three comments requesting clarification of the term “provides” as used in the 
                        <E T="03">manner exception exhausted</E>
                         condition. A couple of commenters asked ONC to clarify that this condition includes only current methods of sharing data, and not former, replaced, or outdated methods of exchange. Another commenter noted that clarification of the term “provide” in this context is even more important, given other proposals related to information blocking that also include concepts like “making available” or “providing.” One comment speculated the definition of 
                        <E T="03">provide</E>
                         included in the HTI-1 Proposed Rule at § 171.102 (information blocking definitions) was included for purposes of this condition, indicating that it was unclear why the definition was proposed and that if finalized in the proposed form, it may add confusion to the provisions of the conditions of information blocking exceptions in general.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We use the word “provide” in § 171.204(a)(4)(iii) without further definition. We unintentionally included a definition of 
                        <E T="03">provide</E>
                         in § 171.102 (information blocking definitions) in the HTI-1 Proposed Rule. We have not finalized any definition of the word “provide” in § 171.102. Further, we emphasize that the definition of 
                        <E T="03">provide</E>
                         finalized in § 170.102 (health information technology certification program 
                        <PRTPAGE P="1386"/>
                        definitions) is not applicable for 45 CFR part 171.
                    </P>
                    <P>
                        We offer the following points of clarification specific, and limited in effect, to our use of the word “provide” in § 171.204(a)(4)(iii). First, as we stated in the preamble of the HTI-1 Proposed Rule, our use of “provide” in the present tense is both precise and deliberative. This factor tests for whether the actor currently provides the same manner to a substantial number of individuals or entities who are similarly situated to any given requestor. Looking only at what the actor 
                        <E T="03">currently</E>
                         provides excludes manners that are nearing or have exceeded the end of their supported life cycles (88 FR 23870). We recommend reviewing the examples in the HTI-1 Proposed Rule related to “provide” in context of § 171.204(a)(4)(iii) and note that they remain appropriate as further explanation of our finalized policy (88 FR 23870).
                    </P>
                    <HD SOURCE="HD3">How should “similarly situated” be determined?</HD>
                    <P>
                        In the HTI-1 Proposed Rule, we discussed that the concept of “similarly situated” is familiar because we also use the phrase in the Fees Exception (§ 171.302) and Licensing Exception (§ 171.303). We noted that it would serve here, as it does there, to indicate that different specific individuals or entities within a class of such individuals or entities who are similarly situated to one another should be treated in a consistent and non-discriminatory manner (88 FR 23871). We also stated that it is not our intent for the “individuals or entities that are similarly situated to the requester” criteria of this new proposed condition to be used in a way that differentiates the same access to EHI simply based on the requestor's status, such as individual (
                        <E T="03">e.g.,</E>
                         a patient) or entity (
                        <E T="03">e.g.,</E>
                         a healthcare system) (88 FR 23871).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters requested that ONC provide more specific information on the types of characteristics that would designate entities as similarly situated and provide examples or guidance on ways for actors to easily group and document that entities are similarly situated. One commenter expressed concern about the lack of clarity related to the “similarly situated” clause. Another commenter argued that the term was inappropriate and what should matter is not the requesting entity's circumstances but its intended purpose of use for the requested interoperability functionality, whether the use aligns with what the functionality was designed to support, and whether the use requires any substantially new development work.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments and have adjusted the finalized policy to address commenters' concerns. As we noted in the preamble to the HTI-1 Proposed Rule, “similarly situated” in the 
                        <E T="03">manner exception exhausted</E>
                         condition's third factor was meant to function in a fashion 
                        <E T="03">similar</E>
                         to the non-discrimination provisions in the Fees and Licensing Exceptions (88 FR 23871). However, with the use of the term “similarly situated,” we were proposing to permit certain discrimination of requestors based on the similarity of their situations to those already being provided access, exchange, or use. As a comparison, we did not permit any discrimination under a parallel construction of one of the factors used for the analysis under the 
                        <E T="03">infeasibility under the circumstances</E>
                         condition of the Infeasibility Exception (
                        <E T="03">compare</E>
                         “Whether the actor's practice is non-discriminatory and the actor provides the same access, exchange, or use of electronic health information to its companies or to its customers, suppliers, partners, and other persons with whom it has a business relationship;” 45 CFR 171.204(a)(5)(i)(D)).
                    </P>
                    <P>
                        We provided guidance in the HTI-1 Proposed Rule on our thinking of how a determination of similarly situated would work. We first provided an example of categorizing requestors into “similarly situated” categories based on the size of the healthcare entity. We then specified that even within these different categories, requestors would not be treated differently based on extraneous factors, such as whether any of them may be competitors of the responding actor or may obtain more of their health IT from the actor's competitors than from the actor (88 FR 23871). Finally, we noted that it was not our intent for the “individuals or entities that are similarly situated to the requester” criteria to be used in a way that differentiates the same access to EHI simply based on the requestor's status, such as individual (
                        <E T="03">e.g.,</E>
                         a patient) or entity (
                        <E T="03">e.g.,</E>
                         a healthcare system).
                    </P>
                    <P>
                        Based on comments received and further consideration of our proposal and examples, we have revised the condition to exclude certain factors from a similarly situated determination and are providing additional clarification and guidance. Consistent with the HTI-1 Proposed Rule, we clarify that “similarly situated” cannot be used to discriminate against requestors based on whether the requestor is a competitor of the actor or whether the requestor will or might use the requested access, exchange, or use in a way that facilitates competition with the actor. Similarly, as we noted above and in the HTI-1 Proposed Rule (88 FR 23871), an actor cannot discriminate in providing a form of access, exchange, or use of EHI that it currently provides to a substantial number of individuals or entities solely based on the requestor's status. In this regard, we are specifically clarifying in regulation text (§ 171.204(a)(4)(iv)) that such statuses include requests by individuals, as we define that term in § 171.202(a), and the health care provider type and size. Regarding health care provider type (
                        <E T="03">e.g.,</E>
                         radiology specialty practice or long-term post-acute care facility) and size, we believe further clarity is necessary based on comments and the example we provided in the HTI-1 Proposed Rule and recited above. While the example in the HTI-1 Proposed Rule may have suggested that size groupings are acceptable, we clarify that such groupings as “similarly situated” would be appropriate in terms of administering costs and licensing agreements under the respective Fees and Licensing Exceptions but would not be appropriate for discriminating in actually providing access, exchange, or use of EHI that the actor provides to a substantial number of individuals or entities. Costs associated with providing access, exchange, or use of EHI or costs associated with licensing interoperability elements, can logically vary based on the size of the entity, so it makes sense to use this category for the Fees and Licensing Exceptions. However, we don't see a similar reason to discriminate based on the entity's size when an actor seeks to satisfy this condition of the Infeasibility Exception because if an actor already provides such access to a substantial number of entities, there is not a parallel correlation that would make it infeasible to provide such access to a “differently” sized requestor.
                    </P>
                    <P>As an example, if a solo practitioner requests access, exchange, or use of certain EHI in the same manner that an actor provides such access, exchange, or use of the same EHI to a large hospital system, then the actor would not be able to discriminate based on the difference between the requestors (large hospital system versus solo practitioner) and still use this condition to cover the practice.</P>
                    <P>
                        Overall, these adjustments are responsive to comments and provide further clarity for the concept of “similarly situated” as it applies to this condition under the Infeasibility Exception.
                        <PRTPAGE P="1387"/>
                    </P>
                    <HD SOURCE="HD3">Other Comments</HD>
                    <P>
                        <E T="03">Comment.</E>
                         One commenter asked that actors be required to report any requests that they have rejected.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment but decline to finalize such a policy at this time as we did not propose such an approach.
                    </P>
                    <P>
                        <E T="03">Comment.</E>
                         A few commenters asked ONC to explain why the first requirement of this new condition restates “technical inability” as the reason for the infeasibility under the Manner Exception when the Manner Exception itself provides that an actor must fulfill the EHI request in the manner requested “unless the actor is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request in the manner requested.” A commenter asked ONC to explain how this alternative requirement in the 
                        <E T="03">manner exception exhausted</E>
                         condition is materially different from the options for meeting the first requirement.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         There is no substantive difference between the “technical inability” under the Manner Exception and this new condition. However, this requirement has been restated as it falls under a new condition and under a different exception. ONC's intent in including the technical infeasibility requirement is to ensure that an actor who cannot, for technical reasons, fulfill a request for any access, exchange, or use of EHI in any manner requested is able to use this condition (provided all other relevant provisions are also met) 
                        <E T="03">and</E>
                         an actor who 
                        <E T="03">does</E>
                         have the technical capability to provide access, exchange, or use of EHI in the manner requested but cannot reach agreeable terms with the requestor may 
                        <E T="03">also</E>
                         make use of this new condition (provided all other relevant provisions are also met). In other words, an actor who can technically fulfill the request but cannot reach agreeable terms can still make use of this condition, so long as all other relevant provisions are met.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received many comments in response to this new condition (and in response to other proposals in the HTI-1 Proposed Rule) advocating we review or revise paragraph (b) of the Infeasibility Exception, which requires an actor that does not fulfill a request for access, exchange, or use of EHI consistent with any of the conditions in paragraph (a) of § 171.204 “provide to the requestor in writing the reason(s) why the request is infeasible” within ten business days of receipt of the request. One commenter noted that requests often come in without the needed level of detail, meaning the developer must ask questions and wait for answers from the requestor before determining whether the request is feasible. In such instances, the commenter stated, the timeliness rests on the requestor and not the responding actor, and therefore a ten-day time frame is insufficient. The commenter further contends that the ten-day clock should “toll” until sufficient information about the request has been received. Other commenters expressed agreement that ten days was too short, too inflexible, and unrealistic. Another commenter asked ONC to clarify that where an actor intends to apply the 
                        <E T="03">manner exception exhausted</E>
                         condition of the Infeasibility Exception that the ten-day time frame begins only after the actor and requestor have not been able to agree on an acceptable alternative manner under the Manner Exception. Another commenter noted that the ten-day time frame was so unrealistic as to preclude the use of the exception in situations where it would otherwise be relevant.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         While we appreciate the comments, we did not propose any changes to the ten-day time frame in the HTI-1 Proposed Rule and are not finalizing any changes to paragraph (b) of § 171.204 in this final rule. We may consider these comments in relation to future regulatory action and guidance.
                    </P>
                    <HD SOURCE="HD3">2. TEFCA Manner Exception</HD>
                    <P>
                        In the HTI-1 Proposed Rule, we proposed to add in § 171.301(c) a 
                        <E T="03">TEFCA manner</E>
                         condition to the proposed revised and renamed Manner Exception codified in 45 CFR 171.301. The proposed condition was stated as follows: “If an actor who is a QHIN, Participant, or Subparticipant offers to fulfill a request for EHI access, exchange, or use for any purpose permitted under the Common Agreement and Framework Agreement(s) from any other QHIN, Participant, or Subparticipant using Connectivity Services, QHIN Services, or the specified technical services in the applicable Framework Agreement, then: (i) The actor is not required to offer the EHI in any alternative manner; (ii) Any fees charged by the actor in relation to fulfilling the request are not required to satisfy the exception in § 171.302; and (iii) Any license of interoperability elements granted by the actor in relation to fulfilling the request is not required to satisfy the exception in § 171.303” (88 FR 23872).
                    </P>
                    <P>
                        In proposing this condition, we sought to offer actors certainty that fulfilling, or even attempting to fulfill, requests for EHI using Connectivity Services, QHIN Services, or the specified technical services in the applicable Framework Agreement (“TEFCA means”) would satisfy the Manner Exception when an actor and requestors are parties to the Common Agreement or a Framework Agreement under the Common Agreement. As proposed, this would have been the case even when the EHI may have exceeded the minimum data classes and elements 
                        <E T="03">required</E>
                         by the Common Agreement as of the date a particular request is fulfilled, assuming the TEFCA means could support the requested access, exchange, or use of the EHI. We stated that the proposed condition could be satisfied regardless of whether the requestor initially requested access, exchange, or use via TEFCA means or some other manner (88 FR 23872). We noted that another important feature of the proposal was that it could be satisfied by the actor either fulfilling or 
                        <E T="03">offering to fulfill</E>
                         the requestor's request for EHI, again, assuming the TEFCA means could support the requested access, and exchange, or use of the EHI. We stated that the approach aligns with the Cures Act's goals for interoperability and the establishment of TEFCA by acknowledging the value of TEFCA in promoting access, exchange, and use of EHI in a secure and interoperable way.
                    </P>
                    <P>We stated that the proposed condition would identify as “reasonable and necessary” an actor's practice of prioritizing use of TEFCA means, in lieu of other feasible manners, for all EHI for which access, exchange, or use can be supported by TEFCA means for both the actor and requestor, so long as the requestor is a TEFCA entity (QHIN, Participant, or Subparticipant) and the purpose is permitted under the TEFCA governing agreements. This would be true regardless of whether the request is initially made through TEFCA means or otherwise; and regardless of whether all of the particular data classes or exchange purposes are yet required by TEFCA's governing agreements to be returned in response to a TEFCA request (88 FR 23873). The condition was designed to provide a clear, efficient regulatory path to prioritize exchange amongst QHINs, Participants, and Subparticipants in TEFCA using TEFCA means of sharing any and all EHI that TEFCA means can support.</P>
                    <P>We requested comment on this proposal and received a substantial number of responses from commenters. These comments are summarized and addressed below.</P>
                    <HD SOURCE="HD3">Summary of Finalized Policy</HD>
                    <P>
                        For the reasons explained below, rather than include this condition as part of the Manner Exception, we have 
                        <PRTPAGE P="1388"/>
                        finalized a new subpart to the information blocking exceptions—Subpart D, “Exceptions That Involve Practices Related to Actors' Participation in The Trusted Exchange Framework and Common Agreement (TEFCA).” The new subpart consists of three sections, § 171.400 “availability and effect of exceptions,” which mirrors §§ 171.200 and 171.300, stating that a practice shall not be treated as information blocking if the actor satisfies an exception to the information blocking provision as set forth in this subpart D by meeting all applicable requirements and conditions of the exception at all relevant times. We have reserved § 171.401 for definitions in future rulemaking and reserved § 171.402 for future use as well. At § 171.403, we finalized a TEFCA Manner Exception that is based on the 
                        <E T="03">TEFCA manner</E>
                         condition proposed in the HTI-1 Proposed Rule.
                    </P>
                    <P>Similar to the proposed condition, the new TEFCA Manner Exception (§ 171.403) provides that an actor's practice of limiting the manner in which it fulfills a request for access, exchange, or use of EHI to providing such access, exchange or use only via TEFCA will not be considered information blocking when the practice follows these conditions:</P>
                    <P>(a) The actor and requestor are both part of TEFCA;</P>
                    <P>(b) The requestor is capable of such access, exchange, or use of the requested EHI from the actor via TEFCA;</P>
                    <P>(c) The request for access, exchange, or use of EHI is not via the standards adopted in 45 CFR 170.215 or version approved pursuant to 45 CFR 170.405(b)(8); and</P>
                    <P>(d) Any fees charged by the actor and the terms for any license of interoperability elements granted by the actor in relation to fulfilling the request are required to satisfy, respectively, the Fees Exception (§ 171.302) and the Licensing Exception (§ 171.303).</P>
                    <P>
                        The first condition, in § 171.403(a), that the actor and requestor are both part of TEFCA, simply means that 
                        <E T="03">both</E>
                         the actor 
                        <E T="03">and</E>
                         the requestor must be either a QHIN, Participant, or Subparticipant, as those terms are defined in the Common Agreement as published at 88 FR 76773. For brevity, in the preamble, we will refer to these three terms collectively as “TEFCA entities” or a “TEFCA entity.” This exception will not be available in any situation where the actor, 
                        <E T="03">or the requestor,</E>
                         is not a part of TEFCA.
                    </P>
                    <P>
                        The second condition, in § 171.403(b), requires that the requestor 
                        <E T="03">must</E>
                         be capable of receiving (accessing, exchanging, or using, depending on the requestor's request) the EHI from the actor, via TEFCA. In the Proposed Rule, we used the term “TEFCA means” to describe fulfilling requests for EHI using Connectivity Services, QHIN Services, or the specified technical services in the applicable Framework Agreement (88 FR 23872, as those terms are defined at 88 FR 76773). In this final rule and in the regulation text, we describe an actor's practice of responding to a request to access, exchange, or use EHI “via TEFCA” to indicate that an actor may use any of the services described by “TEFCA means” consistent with the terms that both the actor and requestor separately agreed to for access to such TEFCA means, and consistent with the other conditions of the exception.
                    </P>
                    <P>
                        As finalized in § 171.403(b), the exception's condition for responding to requests for EHI that the requestor can obtain from the actor via TEFCA uses “via TEFCA” to communicate that the actor makes the EHI available, and the requestor is able to obtain the requested access, exchange, or use of the requested EHI using—what we referenced in the HTI-1 Proposed Rule as making EHI available through “TEFCA means” (88 FR 23872). This includes where Participants and Subparticipants may be exchanging EHI within the same QHIN or across different QHINs. In cases where the requestor is 
                        <E T="03">not</E>
                         capable of accessing, exchanging, or using the EHI via TEFCA, for example because the requestor does not support such exchange methods or its QHIN does not, an actor would not be able to make use of this exception.
                    </P>
                    <P>
                        The third condition, in § 171.403(c), excludes requests from the exception where the requestor seeks to access, exchange, or use EHI via the “Application Programming Interface Standards,” (or API standards) (45 CFR 170.215) adopted by ONC on behalf of the Secretary or another version of those standards approved pursuant to the “Standards Version Advancement Process” (45 CFR 170.405(b)(8)) under the ONC Health IT Certification Program. When a requestor seeks to access EHI via those API standards (essentially FHIR-based standards), an actor 
                        <E T="03">cannot</E>
                         use this exception. In other words, the third condition functions as a carve-out in that the exception is not available if the requestor requested access, exchange, or use of EHI via the API standards.
                    </P>
                    <P>The fourth and final requirement for this condition, in § 171.403(d), states that any fees an actor charges, and any licensing terms an actor sets, must comply with the Fees Exception (§ 171.302) and the Licensing Exception (§ 171.303). This exception in § 171.403 would not be available in any situations where all four of these conditions are not satisfied.</P>
                    <P>
                        Rather than finalize the proposed definitions, in order to maintain consistency between the most current version of the Common Agreement and this regulation, we have decided to refer to the definitions used in the Common Agreement (88 FR 76773) for the terms used in this exception. The relevant definitions are similar to, or the same as, the terms we proposed to define in the proposed 
                        <E T="03">TEFCA manner</E>
                         condition. For example, when we refer to Framework Agreement(s), we mean any one or combination of the Common Agreement, a Participant-QHIN Agreement, a Participant-Subparticipant Agreement, or a Downstream Subparticipant Agreement, as applicable. A Qualified Health Information Network (QHIN) is, as defined in the most recent version of the Common Agreement, a health information network (as defined in § 171.102) that is a U.S. entity that has been designated by the Recognized Coordinating Entity (RCE) and is a party to the Common Agreement countersigned by the RCE. Both Participant and Subparticipant are defined as they are in the Common Agreement (88 FR 76773). In some cases, such as with the term Connectivity Services, the definition proposed is different from the most recent version of the Common Agreement, where it is defined as the technical services provided by a QHIN consistent with the requirements of the then-applicable QHIN Technical Framework and pursuant to the Common Agreement with respect to all Exchange purposes. The Common Agreement also defines Individual Access Services (IAS) as the services provided to an Individual by a QHIN, Participant, or Subparticipant that has a direct contractual relationship with such Individual in which the QHIN, Participant or Subparticipant, as applicable, agrees to satisfy that Individual's ability to access, inspect, or obtain a copy of that Individual's Required Information using TEFCA Exchange. We decided to reserve 171.401 for possible future use to incorporate these definitions into the regulatory framework.
                    </P>
                    <HD SOURCE="HD3">Timeliness of Exception</HD>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters stated that it would be premature to adopt this proposal. Commenters noted that TEFCA is in its early stages and has not yet launched. Others suggested ONC take a “wait and see” approach, monitor TEFCA deployments for utility, completeness, timeliness, ease of access, 
                        <PRTPAGE P="1389"/>
                        security, privacy, transparency, and consumer participation, and then finalize an exception only if real world experience demonstrates a need. A commenter noted that TEFCA is a voluntary program that does not support the full breadth of use cases for EHI, and that such an exception will designate other pathways as “less interoperable” even if they have equal or greater utility compared to exchange through TEFCA. Another commenter appreciated ONC's support for greater interoperability, but also stated it was too soon to establish this condition because it could result in less sharing of information in the early stages of TEFCA's development. The commenter suggested, as an alternative, that TEFCA-based exchange should be included as a preferred approach to sharing EHI, but not in a way that enables an actor to deny a request if the requestor cannot receive it via TEFCA-based exchange.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback. The policy as proposed (88 FR 23873) and as finalized in the new TEFCA Manner Exception is only available when both the actor and the requestor are in TEFCA, which we believe eliminates the concerns about the timeliness of identifying as reasonable and necessary the practices that satisfy the exception. Entities will join TEFCA with the expectation that they will exchange EHI using TEFCA when possible. This exception reinforces that practice. No actor is required to join TEFCA, so those that do so will do so with the knowledge that this exception is available in certain circumstances. As a voluntary exception, no actor is required to make use of the exception—which we believe further negates the timeliness concerns. In addition, an actor will 
                        <E T="03">not</E>
                         be able to use this exception if, for whatever reason, the requestor is not capable of accessing, exchanging, or using the requested EHI via TEFCA. In such cases, an actor would need to provide the EHI in the manner requested, or in an alternative manner agreed upon with the requestor or use another exception to cover the practice to attain certainty that the actor's practice will not be considered information blocking.
                    </P>
                    <HD SOURCE="HD3">Fees and Licensing Terms Concerns</HD>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters expressed concern that we did not propose to apply the restrictions found in the Fees Exception (§ 171.302) and the Licensing Exception (§ 171.303) to this condition. These commenters contended that, without such application, actors would be able to charge outrageous fees or set unreasonable licensing terms for interoperability elements. Other commenters noted that such fees could interfere with an individual's right to access their EHI. A couple of commenters asserted that, as proposed, the condition could result in applications that charge patients for their services as the only realistic way for patients to get their EHI. Some commenters further asserted that because the only fees that are prohibited in the Common Agreement are fees charged between QHINs, Participants and Sub-participants would be able to charge fees for exchange of EHI that would not need to satisfy the Fees Exception.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments and believe the commenters raised valid concerns. In fact, when proposing the 
                        <E T="03">TEFCA manner</E>
                         condition, we mistakenly assumed that all actors participating in TEFCA would have 
                        <E T="03">already</E>
                         reached overarching agreements on fees and licensing such that there would be no need for application of the Fees and Licensing Exceptions. (
                        <E T="03">See</E>
                         88 FR 23872, “[the proposal] facilitates an actor reaching agreeable terms with a requestor to fulfill an EHI request and acknowledges that certain agreements 
                        <E T="03">have been reached</E>
                         for the access, exchange, and use of EHI (for example, by using standards consistent with the Common Agreement or applicable flow-down Framework agreements that the actor and requestor have agreed to abide by)” (emphasis added)). In fact, the Common Agreement is silent on fees except to forbid QHINs from charging fees to other QHINs. Therefore, to correct our misunderstanding and in consideration of comments, we have finalized the exception to include that any fees charged by the actor, and any licensing of interoperability elements, must satisfy the Fees Exception (§ 171.302) and the Licensing Exception (§ 171.303). It was never our intent to permit fees or licensing agreements that would not satisfy the information blocking regulations, either by being agreed to ahead of time, as we presumed, or by satisfying the Fees and Licensing Exceptions.
                    </P>
                    <HD SOURCE="HD3">Concerns Regarding EHI Accessibility and Fees for Individuals</HD>
                    <P>
                        <E T="03">Comments.</E>
                         Many requestors expressed concerns that the proposed TEFCA condition would interfere with an individual's access to their own EHI. One commenter stated that the condition could be used to elect out of participating in Individual Access Services in a national network capacity. The commenter stated that while responding to individual requests via TEFCA is required (by the Common Agreement), QHINs are not required to initiate support for Individual Access Services. One commenter expressed concerns that the exception will make it more difficult for patients to get provider and payer data, and that patients who do not understand how networks function will be disadvantaged compared to others. A few commenters expressed concern about patient matching within the TEFCA network. One commenter expressed concerns about sensitive data, citing reproductive health care as an example, and how a patient could control access to such EHI. Some commenters indicated they were especially concerned with patient privacy and the ability for applications to charge for access to patient data or possibly “traffic” EHI through “dark data” exchanges. A commenter encouraged ONC to focus on FHIR-based interoperability. A few commenters expressed concerns that the proposal would allow actors to charge individuals for access to their own data. Another commenter expressed significant concerns that the exception would permit charging fees to Individual Access Services (IAS) providers who are looking to access healthcare data on behalf of individuals.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments. Consistent with our proposal, the policy, as finalized, is applicable only when both the actor and the requestor are part of TEFCA (88 FR 23873, 
                        <E T="03">see also</E>
                         88 FR 23917-23918). We would like to assure commenters that this exception cannot be used in any case when an individual is requesting EHI, because an individual cannot be a QHIN, Participant, or Subparticipant under TEFCA. If the individual is using TEFCA's Individual Access Services to query for or retrieve EHI via TEFCA instead of seeking to access, exchange, or use EHI directly from their health care provider's portal or FHIR APIs, then the QHIN, Participant, or Subparticipant, in its role as an IAS provider, would be querying via TEFCA, 
                        <E T="03">not</E>
                         the individual. Furthermore, as described previously, the finalized exception includes the requirement that any fees charged for the access, exchange, or use of the EHI must satisfy the Fees Exception (§ 171.302), which specifically prohibits charging a patient (including a third-party app on the patient's behalf) for API or other electronic access to the patient's EHI (§ 171.302(b)(1) and (2)). Regarding patient privacy, all § 171.102 actors are required to protect patients' privacy and restrict the access, exchange, and use of 
                        <PRTPAGE P="1390"/>
                        EHI as required by all applicable law, including, but not limited to, the HIPAA Privacy Rule for actors to whom the HIPAA Privacy Rule applies.
                    </P>
                    <P>Patient matching within TEFCA is addressed by applicable policy and technical procedures as well as associated agreements under TEFCA. For purposes of information blocking, any actor who receives a request for access, exchange, or use of EHI that the actor knows, or reasonably suspects, is misidentified or mismatched and who seeks certainty as to the conditions under which they can withhold such EHI without engaging in information blocking will want to consult the Preventing Harm Exception in 45 CFR 171.201, which recognizes this type of risk in § 171.201(c)(2).</P>
                    <HD SOURCE="HD3">Concerns Regarding Interoperability and FHIR APIs</HD>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters expressed concerns with the limited manner of exchange initially available in TEFCA and noted that when TEFCA officially launches, the Common Agreement will require only IHE document-based exchange. Commenters stated that restricting TEFCA entities to IHE document-based exchange would limit the use of EHI exchanged in that manner, would limit interoperability by not requiring the use of modernized exchange protocols like FHIR, and could even disincentivize joining TEFCA. Others noted that our proposal would push actors to one exchange mechanism over another, which would remove choice and optionality and could potentially eliminate or discourage use of other exchange options, such as FHIR APIs, that may be preferable for some use cases. A few commenters noted that many health IT developers of certified health IT plan to connect their customers to TEFCA such that their customers will have to actively choose to opt out. Commenters expressed concerns that most actors will likely be Participants or Sub-participants and, therefore, “subject to this exception.” As a result, one of these commenters stated that most of the information blocking regulations would be folded into the TEFCA framework, which lags behind today's use of FHIR APIs.
                    </P>
                    <P>Other commenters noted that requestors may have practical reasons to ask for EHI in ways other than what TEFCA supports. Commenters encouraged ONC to advance support for HL7 FHIR within TEFCA as quickly as possible to allow third-party applications to access data more easily on behalf of individuals. A few commenters noted that section 4003(a) of the Cures Act defined interoperability as health information technology that enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user. The commenters claimed that the proposed TEFCA condition would require special effort on the part of the user, particularly with the use of IHE document protocol. Other commenters stated that entities should be able to choose the best interoperability mechanisms and request data in any format the current source can reasonably support using an exchange mechanism both can support. A commenter stated that, because there may be a delay before TEFCA widely implements the use of FHIR for all of the stated “exchange purposes,” organizations should be able to negotiate for the manner of access that best suits their requirements. In particular, the commenter stated that organizations should be allowed to prioritize using EHR systems' SMART on FHIR patient API endpoints, and for population-level use cases, bulk FHIR export, even if TEFCA supports access to such EHI in another manner.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their feedback. Currently, TEFCA includes IHE document-based exchange, but publicly available documents note that FHIR exchange is a TEFCA priority and is planned for availability in 2024. IHE document-based exchange is a longstanding standard for exchanging EHI. For example, organizations supporting health information exchange nationally (
                        <E T="03">e.g.,</E>
                         CommonWell Health Alliance, eHealth Exchange, Carequality) generally use IHE profiles such as Cross-Community Patient Discovery (XCPD) 
                        <SU>258</SU>
                        <FTREF/>
                         and Cross-Community Access (XCA) 
                        <SU>259</SU>
                        <FTREF/>
                         to enable clinical document exchange between disparate communities.
                        <SU>260</SU>
                        <FTREF/>
                         However, as many commenters pointed out, FHIR-based exchange has certain advantages over IHE document-based exchange. Over time, QHINs, Participants, and Subparticipants may well be required to support broader uses of FHIR-based exchange, but it is also likely that many Participants and Subparticipants will continue to use document-based exchange instead of FHIR-based exchange for several transition years.
                        <SU>261</SU>
                        <FTREF/>
                         In addition, the information blocking exceptions are all voluntary and are not “required” of any actor. The exceptions serve to offer certainty to actors that by conforming a practice to the conditions of an exception, such practice will not constitute information blocking. A Participant or Subparticipant in TEFCA is not “subject to” any exceptions, but if such entity is an actor (as defined in § 171.102), the new finalized exception would be available along with all the other exceptions.
                    </P>
                    <FTNT>
                        <P>
                            <SU>258</SU>
                             IHE Cross-Community Patient Discovery (XCPD) profile—available in the IHE IT Infrastructure (ITI) Technical Framework Volume 1: Integration Profiles at: 
                            <E T="03">https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev17-0_Vol1_FT_2020-07-20.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>259</SU>
                             IHE Cross-Community Access (XCA) profile—available in the IHE IT Infrastructure (ITI) Technical Framework Volume 1: Integration Profiles at: 
                            <E T="03">https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev17-0_Vol1_FT_2020-07-20.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>260</SU>
                             
                            <E T="03">https://rce.sequoiaproject.org/wp-content/uploads/2022/01/QTF_0122.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>261</SU>
                             
                            <E T="03">https://www.healthit.gov/buzz-blog/tefca/coming-in-hot-tefca-will-soon-be-live-and-add-support-for-fhir-based-exchange.</E>
                        </P>
                    </FTNT>
                    <P>
                        In consideration of both our stated goal to incentivize TEFCA participation and comments suggesting that ONC should be promoting the use of FHIR-based APIs (for example, the standards codified in 45 CFR 170.215, “Application Programming Interface Standards”), we have limited the finalized exception's availability. Specifically, in instances where an actor that is part of TEFCA receives a request to access, exchange, or use EHI via the API standards adopted in 45 CFR 170.215, including updated versions of such standards as may be approved for voluntary use in the ONC Health IT Certification Program pursuant to 45 CFR 170.405(b)(8), the Standards Version Advancement Process, the actor 
                        <E T="03">cannot</E>
                         meet the finalized TEFCA Manner Exception. We finalized this policy in § 171.403(c), providing a limitation on the use of the exception in that it does not apply to a request for access, exchange, or use of EHI via the standards adopted in 45 CFR 170.215, including version(s) of those standards approved pursuant to 45 CFR 170.405(b)(8). This approach ensures that requestors seeking to access, exchange, or use EHI via FHIR-based APIs can request such access and be assured that an actor cannot use the TEFCA Manner Exception to limit the manner in which it fulfills the request to only via TEFCA. As many commenters noted, FHIR APIs advance interoperability to a greater degree than IHE document-based exchange, which is a currently permitted exchange mechanism under TEFCA. With the goals of the proposed condition to acknowledge agreements reached by parties and to promote both interoperability and TEFCA adoption (88 FR 23872-23873), the FHIR-based API limitation in § 171.403(c) is necessary to achieve these goals.
                        <PRTPAGE P="1391"/>
                    </P>
                    <P>
                        It is crucial to note that an actor (
                        <E T="03">e.g.,</E>
                         a health IT developer of certified health IT) that participates in the ONC Health IT Certification Program cannot simply “turn off” API capabilities, outside of TEFCA, to avoid offering such access, exchange, or use to a requestor. Any developer that has chosen to participate in the Program is subject to the Conditions of Maintenance and Certification requirements in subpart D of 45 CFR part 170. The API Condition and Maintenance of Certification requirements in § 170.404 apply to health IT developers that certify health IT to FHIR-based API certification criteria. Such developers would not be compliant with the API Condition and Maintenance of Certification requirements if they do not, among other requirements, publish APIs and allow EHI access, exchange, and use through the APIs. Any actor with certified health IT who has deployed “certified API technology” (as defined in § 170.404(c)) or other API technology using the standards and implementation specifications adopted in § 170.215, who disables, disconnects, or otherwise “turns off” such API technology or requestors' connections in order to avoid offering such access, exchange, or use after joining TEFCA would do so explicitly outside the applicability of the TEFCA Manner Exception finalized in § 171.403 and such practices could constitute information blocking.
                    </P>
                    <P>The TEFCA Manner Exception, as finalized, is not in conflict with the PHSA section 3000(9) definition of “interoperability” or with other ONC regulations. The exception only applies to entities that choose to voluntarily participate in TEFCA and agree to the interoperability means available under TEFCA, while also preserving the availability of interoperable FHIR APIs to requestors for the access, exchange, and use of EHI.</P>
                    <P>In sum, we believe that the proposed approach would not have led to most of the negative consequences for FHIR API adoption theorized by commenters. However, to address such confusion and concern and continue to incentivize TEFCA participation, in § 171.403(c), we have finalized the explicit limitation condition within the exception to remove any doubt about perceived conflicts between TEFCA and FHIR API adoption. ONC has been and will continue to be at the forefront of driving both TEFCA and FHIR API adoption across the industry and the Federal Government.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters noted that some EHI requestors who will likely be part of TEFCA may not have the technical capability to make requests or receive responses for certain permitted but optional exchange purposes.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In situations where a requestor does not support the capability to make or receive requests or perform other transmissions for certain Exchange Purposes (including those that do not require a response), the TEFCA Manner Exception would not be available because the requestor would not have such access, exchange, or use of the EHI consistent with the 
                        <E T="03">requestor capability</E>
                         condition in paragraph (b) of § 171.403.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters stated that the proposed TEFCA manner condition could interfere with state reporting requirements, because, for example, some states require payers to exchange data within a specified network based on existing federal rules. One commenter stated that the condition risked discriminating against mechanisms of exchange and interoperability that are feasible and even required to be used by regional or local authorities. Another commenter stated that the inclusion of this exception demonstrates that there may be conflicting or confusing mandates under different federal programs, making compliance with information blocking regulations more difficult. The commenter urged ONC to continue to review how all federal and state laws, regulations, and programs interact to relieve the unnecessary burden of varying requirements that may not align. A commenter stated that the proposed condition risks discriminating against exchange mechanisms and interoperability pathways that are otherwise commercially and technically feasible, and in some cases, required under law. The commenter noted that a diversion of such exchanges to TEFCA would result in the loss of useful information that should be added to the patient's record to provide additional context for clinical care.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments. We remind commenters that the exceptions exist as a voluntary means for actors to gain assurance that their practice(s) does not constitute information blocking; and similarly, participating in TEFCA is voluntary. Compliance with an exception set forth in subpart B, C, or newly finalized D of 45 CFR part 171, would mean that an actor's practice does not meet the definition of information blocking in § 171.103. However, this would not, in or of itself, immunize the actor from any other consequences to which they are subject to for violating, ignoring, or otherwise failing to comply with other applicable laws.
                    </P>
                    <P>
                        In response to concerns that the exception risks discriminating against exchange mechanisms and interoperability pathways that are otherwise commercially and technically feasible, we note that a requestor can request EHI in any manner, and an actor may seek to satisfy the 
                        <E T="03">manner requested</E>
                         condition of the Manner Exception (§ 171.301(a)) and respond in that manner, if the actor and requestor can come to agreeable terms for the access, exchange, and/or use of the particular EHI. In such instances, the terms of the agreement need not satisfy the Fees Exception (§ 171.302) or the Licensing Exception (§ 171.303), and would meet the 
                        <E T="03">manner requested</E>
                         condition of the Manner Exception (§ 171.301). Using the TEFCA Manner Exception is voluntary, and in cases where a requestor would be unable to use its preferred exchange method it could negotiate with the actor under the 
                        <E T="03">manner requested</E>
                         condition (§ 171.301).
                    </P>
                    <P>The TEFCA Manner Exception does not require actors to use TEFCA to meet public health reporting requirements under other applicable laws. Similarly, the TEFCA Manner Exception does prohibit the use of other exchange methods. Rather, it acknowledges an exchange method (manner) that both the actor and requestor have voluntarily chosen to use, and are capable of using, as a method that would be reasonable and necessary for purposes of not being considered information blocking. As noted above, actors are still responsible for their other legal obligations, such as under state law.</P>
                    <P>Regarding the concern about exchanging requested EHI only via TEFCA when doing so would result in the loss of some of the responsive EHI that the actor has and can (consistent with applicable law and patient privacy preferences) make available to the requestor for the purpose(s) applicable to the request, then this exception is not available to the actor. The finalized TEFCA Manner Exception applies only to the EHI that the actor is actually able to make available for access, exchange, or use via TEFCA and that the requestor is capable of accessing, exchanging, or using, as applicable, via TEFCA (§ 171.403(b)).</P>
                    <HD SOURCE="HD3">Incentivizing TEFCA Participation</HD>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters encouraged ONC to consider that while this condition will be useful for those already in TEFCA, it will not meaningfully incentivize participation in TEFCA. As an example, some state agencies that do not have the technological resources to adopt TEFCA technical services will contract with a 
                        <PRTPAGE P="1392"/>
                        third-party entity and end up passing the cost of the contracts on to others, including health care providers. Some commenters asked for a “safe harbor” period to allow participants to fully embrace TEFCA. A commenter expressed concern that the condition will discourage third-party apps from joining TEFCA because they will have more flexibility to request data outside of TEFCA.
                    </P>
                    <P>Many other commenters, however, agreed that the proposal will incentivize and accelerate use of the available, interoperable, and secure TEFCA technical services by TEFCA entities. Commenters noted that the proposal would reinforce the transition to standards-based exchange and prevent actors from unnecessarily devoting limited time and resources to fulfilling burdensome, customized solutions. A commenter appreciated strong regulatory incentives to join TEFCA.</P>
                    <P>A commenter expressed concern that the proposed condition could be used to coerce use of TEFCA or be used as a defense to evade fulfilling a request for access, exchange, or use of EHI when the requestor does not use TEFCA for a permitted purpose for data beyond USCDI v1. Another commenter suggested ONC use the policy exactly that way and require only the actor be a part of TEFCA. The commenter contended that if the requestor can receive the access, exchange, or use of EHI via TEFCA and is eligible to join TEFCA, the actor should only be required to offer EHI via TEFCA in order to satisfy the exception (in other words, make the requestor join TEFCA to get the requested access, exchange, or use of EHI).</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments. We recognize that this condition incentivizes, to differing degrees for different actors, joining TEFCA, and that not all entities will be ready, willing, or able to join TEFCA as soon as the first technical services under TEFCA go “live.” However, we do not agree that a safe harbor period is needed, as both joining TEFCA and using the exceptions are voluntary and function only to offer actors certainty that their practices that meet all relevant conditions of an exception, at all relevant times, will not constitute information blocking.
                    </P>
                    <P>At this time, we decline to use this exception as a means to propel requestors into joining TEFCA or to justify, to us or to actors, why they are not yet TEFCA entities. Such an approach is beyond what our proposal or finalized exception is intended to achieve and may actually undermine and frustrate the intent of the information blocking statute and implementing regulations. We also recognize the concern that some actors may wish to use the exception to evade fulfilling a request for access, exchange, or use of EHI when the requestor does not use TEFCA for a permitted purpose beyond USCDI v1. Attempts to misuse the exception in that way would not be successful because, for the exception to apply to an actor's practice of making EHI available only via TEFCA, the requestor must be capable via TEFCA of, as applicable, accessing, exchanging, or using the requested EHI from the actor. The condition in § 171.403(b), as finalized, addresses concerns about limits to what EHI requestors can access via TEFCA by ensuring the condition is only available when the EHI the requestor seeks can, in practice, be accessed, exchanged, or used by the requestor via TEFCA.</P>
                    <HD SOURCE="HD3">Structuring the Exception Within the Existing Regulatory Framework</HD>
                    <P>In creating a new subpart and finalizing a separate exception, we have made it easier for actors and requestors to understand when an actor's fulfillment of EHI access, exchange, or use only via TEFCA would not constitute information blocking. By creating a new subpart, we are clearly delineating that the exception is available only to TEFCA participants. Also, by removing it from the Manner Exception, we avoid introducing confusion about when an actor must offer alternative manners and in what order they must do so. Further, in creating this new subpart, we leave room for identifying other reasonable and necessary activities related to TEFCA that do not constitute information blocking, should we propose them in future rulemakings.</P>
                    <HD SOURCE="HD3">EHI That Can Be Made Available Versus EHI That Must Be Made Available via TEFCA</HD>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters stated that because TEFCA only requires the exchange of the USCDI, the exception will be of limited utility. Another commenter asked for clarity that EHI can exceed the base set of EHI required by TEFCA. Other commenters appreciated that the condition would not be limited to a subset of EHI, so long as the EHI could be accessed, exchanged, or used by the requestor, as applicable.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback. As finalized, the exception can be satisfied when any EHI requested by the requestor can be made available to the requestor via TEFCA for the requested access, exchange, or use of the EHI, including where the EHI requested is beyond what is represented by the data elements within any USCDI version. Nothing in this exception restricts how much or which EHI can be shared via TEFCA or limits the exception's application to the minimum data elements that TEFCA's terms require TEFCA entities to make available in response to TEFCA queries. If an actor is capable of sharing all the requested EHI via TEFCA, and, importantly, the requestor is capable of accessing, exchanging, or using all of the EHI via TEFCA, as applicable, then the exception could apply to the practice (if all other conditions are also satisfied). Similarly, if an actor is capable of providing access, exchange, or use of some, but not all, of the requested EHI via TEFCA, the exception can cover the practice for the EHI that the actor 
                        <E T="03">is</E>
                         capable of providing via TEFCA and the requestor is capable of accessing, exchanging, or using (as applicable). The actor could then provide the remaining EHI in a different manner, for example, by using any of the methods in the Manner Exception (§ 171.301), or resolve the request through other means or applicable information blocking exceptions.
                    </P>
                    <HD SOURCE="HD3">Other Concerns and Observations From Commenters</HD>
                    <P>
                        <E T="03">Comments.</E>
                         A couple of commenters stated that, in some cases, one business unit may sign up for TEFCA, in which case the entire organization would also become part of TEFCA. The commenters stated that in such cases, a requestor may be unaware that they are considered a part of TEFCA, may not have the technical capability to connect their IT systems to the TEFCA network, and will want to receive EHI in another manner.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for the feedback. The § 171.403(b) 
                        <E T="03">requestor capability</E>
                         condition of the finalized TEFCA Manner Exception ensures that the exception is only available when the requestor is capable via TEFCA of accessing, exchanging, or using, as applicable, the requested EHI from the actor at the time the request is made. We cannot anticipate every corporate arrangement; however, if a requester's organization is a party to the Common Agreement or a Framework Agreement, it is the requester's responsibility to resolve its approach to EHI access, exchange, and use within the organization.
                    </P>
                    <HD SOURCE="HD3">Agreed Upon by the Requestor</HD>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters noted that, under the Manner Exception, a requestor must agree to access, 
                        <PRTPAGE P="1393"/>
                        exchange, or use of EHI if the actor offers to fulfill the request in any alternative manner. The commenters stated that, in the proposed 
                        <E T="03">TEFCA manner</E>
                         condition, requestors would not be required to agree to receive the EHI via TEFCA. They noted that this shifts the balance of power towards actors and away from requestors. Commenters expressed concerns that the requestor cannot counter with an alternative manner and are forced to accept via TEFCA. Other commenters appreciated that the condition would simplify responses for many actors who participate in TEFCA and allow requestors and actors to exchange EHI more efficiently.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In the Manner Exception, one policy objective is to ensure the requestor receives the EHI in either the manner requested or in an alternative manner to which the requestor agrees. This policy assumes that the requestor would not agree to an alternative manner unless that manner allowed them the access, exchange, or use of EHI which they sought in the first place. In finalizing the TEFCA Manner Exception, this policy objective is fulfilled by two conditions. The requestor has agreed to be part of TEFCA and the 
                        <E T="03">requester capability</E>
                         condition, which states that the requestor is capable, via TEFCA, of accessing, exchanging, or using, as applicable, the EHI requested from the actor. Although the requestor does not have to agree to receive the EHI via TEFCA, the requestor did voluntarily join TEFCA, and assuming the requestor has the necessary capabilities, the requestor will still be able to access, exchange, and/or use the EHI, as applicable. In other words, even if the requestor does not agree to a specific instances of access, exchange, or use of EHI via TEFCA, the TEFCA Manner Exception is still available to the actor for providing such access via TEFCA, so long as an actor has satisfied all of the conditions of the exception at all relevant times. We believe this approach balances the policy interest of promoting interoperability and TEFCA participation with the interest in ensuring EHI moves in a manner that is usable by the requestor.
                    </P>
                    <P>We also note that the comment and similar comments assume that TEFCA participation will not streamline information exchange. Those who join TEFCA are voluntarily seeking to get the benefits of scalable nationwide trust and infrastructure services for IHE-based and, as the transition to FHIR takes place, FHIR API exchange. Thus, those who join TEFCA would be motivated to fulfill as much of their information sharing obligations and practices as they are able to in order to reduce the overhead associated with achieving interoperability outside of TEFCA. In short, rather than hampering information sharing, we believe that encouraging exchange via TEFCA will make it easier for both actors and requestors to achieve access, exchange, and use of the EHI.</P>
                    <P>
                        Finally, to clarify the distinction between the Manner Exception (§ 171.301) and its conditions (a) 
                        <E T="03">manner requested</E>
                         and (b) 
                        <E T="03">alternative manner,</E>
                         we have finalized a new subpart D, “Exceptions That Involve Practices Related to Actors' Participation in The Trusted Exchange Framework and Common Agreement (TEFCA)” and finalized the TEFCA Manner Exception within that subpart at § 171.403.
                    </P>
                    <HD SOURCE="HD3">Concerns About TEFCA Policies</HD>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter asked for clarification about how to distinguish exchange that occurs pursuant to a Framework Agreement versus an intra-QHIN agreement. The same commenter also asked how actors will be able to ascertain whether a request made for a certain purpose (
                        <E T="03">e.g.,</E>
                         health care operations) outside the TEFCA network aligns with the same purpose that they (the actors) would be offering to respond to under TEFCA; and how to handle situations where a requestor does not support the capability to make or receive requests or perform other transmissions for certain Exchange Purposes that do not require a response (
                        <E T="03">e.g.,</E>
                         Payment, Public Health, or health care operations). Another commenter asked ONC to clarify which purposes are permitted under TEFCA as applied to this exception. One commenter asked that ONC clarify that if the EHI being requested or the exchange purpose for which it was requested are not part of the current required parameters of TEFCA, the condition will still be available.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         QHIN-to-QHIN exchange would be covered by this exception because both parties, the QHINs, are “part of TEFCA,” having signed the Common Agreement to become a QHIN. Exchange 
                        <E T="03">within</E>
                         QHINs (in other words, exchange between Participants or Subparticipants who have joined the same QHIN) would also qualify for this exception. In addition, the purpose of the request is not relevant for the information blocking definition, nor is the status of the parties beyond their being “part of TEFCA.” So long as the actor can respond to the request via TEFCA, and the requestor participates in TEFCA and is capable of access, exchange, or use of the EHI, as applicable, then the condition can be satisfied, assuming all the other conditions of the exception are also met. In situations where a requestor does not support the capability to make or receive requests or perform other transmissions for certain Exchange Purposes that do not require a response, then the TEFCA Manner Exception would not be available because the requestor would not be able to access, exchange, or use the EHI if transmitted via TEFCA, and thus the second condition of the exception, 
                        <E T="03">requestor capability</E>
                         (§ 171.403(b)) would not be met.
                    </P>
                    <HD SOURCE="HD3">TEFCA Directory</HD>
                    <P>ONC requested comment on whether an actor should be required to search a directory prior to responding via TEFCA (88 FR 23873).</P>
                    <P>
                        <E T="03">Comment.</E>
                         One commenter expressed concerns that the directory would be unreliable, or that actors may not be recognized due to naming issues. Another commenter asked if QHINs would be permitted to leverage their own provider directories.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their feedback. At this time, for reasons such as those mentioned by the commenter as well as due to the logistical complexities of providing real-time access to an easily usable directory for purposes of identifying requestors of EHI, we have not finalized a requirement that an actor search the TEFCA directory as a condition of the exception. Actors should be able to determine whether requestors are part of TEFCA through customary business interactions, such as those that occur when parties engage in exchanging EHI. Actors may also choose to use their own resources, such as provider directories, to make affirmative determinations of whether a requestor is part of TEFCA. However, it ultimately remains the actor's responsibility in making a positive determination as to whether a requestor is part of TEFCA for the purposes of satisfying this exception.
                    </P>
                    <HD SOURCE="HD3">General Comments</HD>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters recommended that ONC restrict the scope of the proposed exception such that it covers only those reasonable activities that are necessary to comply with and implement the Common Agreement, and not to extend it to other practices. Commenters noted this would still incentivize TEFCA participation without inadvertently inhibiting innovation and competition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         While we appreciate the commenter's position and agree that 
                        <PRTPAGE P="1394"/>
                        such an exception may incentivize TEFCA participation, the finalized TEFCA Manner Exception will provide certainty to actors that the practice of making EHI available for access, exchange, and use via TEFCA to other TEFCA participants, and consistent with the relevant outlined conditions, will not be information blocking. We may consider proposing additional TEFCA exceptions in future rulemakings.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed support for the exception, stating that it would reduce burden on physicians who connect to a QHIN by allowing physicians to rely on that connection as a substitute for fulfillment of tailored requests for EHI by redirecting the requestor to the QHIN.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We want to clarify that, as proposed and as finalized, the TEFCA Manner Exception does not permit physicians to redirect all requests for access, exchange, or use of EHI to a QHIN. However, TEFCA participation and meeting the exception in applicable circumstances may allow physicians to redirect a significant portion of EHI requests. The exception outlines the specific circumstances under which an actor, who is part of TEFCA, may respond to a requestor, who is also part of TEFCA, via TEFCA services regardless of the manner requested, unless the requestor asked for the access via the standards adopted in 45 CFR 170.215, including versions of those standards approved pursuant to 45 CFR 170.405(b)(8). Further, the requestor must be capable of accessing, exchanging, or using the EHI, as applicable to the circumstances, via TEFCA. Therefore, there will be circumstances when both the actor and requestor may be part of TEFCA, but the exception would not apply because the requestor cannot, for technical reasons or due to TEFCA-related agreements, access, exchange, or use the EHI via TEFCA. We also emphasize, again, that individuals cannot be “part of TEFCA;” thus, if the requestor is an individual, the TEFCA Manner Exception will not be available to any actor.
                    </P>
                    <P>
                        <E T="03">Comment.</E>
                         A commenter suggested ONC simplify the information blocking regulations and create separate exceptions/conditions for providers different from those for developers and networks and explore provider-targeted exception options not tied to certified Health IT Module use or TEFCA participation.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment, but we did not propose exceptions specific to any one of the three categories of actors (health care provider, HIN/HIE, and health IT developer of certified health IT), and decline to adopt such an approach in this final rule. The exceptions address reasonable and necessary activities that are not considered information blocking and are designed to be used by any of the regulated actors where appropriate. Generally, they are not contingent on the use of certified health IT. Further, all of the exceptions set forth in subparts B and C of 45 CFR part 171 are available to any actor, when they are satisfied, regardless of whether the actor has chosen to become a part of the TEFCA ecosystem. Health care providers interested in learning more about any or all of the information blocking exceptions can find more information about the exceptions at 
                        <E T="03">https://www.healthit.gov/topic/information-blocking.</E>
                         The exceptions themselves can be found in their entirety in 42 CFR part 171 (available online at: 
                        <E T="03">https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-171?toc=1</E>
                        ).
                        <SU>262</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>262</SU>
                             URLs retrieved Oct 26, 2023.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Comments Beyond the Scope of the Proposal</HD>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter asked for clarification regarding the participation of entities in TEFCA that are acting on behalf of other entities, like business associates, and the data sharing requirements for those entities.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment. The regulations and requirements governing TEFCA are out of scope for the proposal.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter asked ONC to better explain the controls that are in place to ensure that QHIN requested data does not violate HIPAA. Another commenter asked ONC to address how patients will provide consent for the networked sharing of their data via TEFCA, and how patients will even be informed about what of their data has been shared by whom, to whom, and for what use. A few commenters asked ONC to incorporate privacy-protective practices into the Common Agreement.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         These comments are beyond the scope of the proposal. However, we offer the following information in response to these comments about TEFCA. TEFCA includes strong privacy protections within the Common Agreement, Qualified Health Information Network Technical Framework (QTF), and standard operating procedures. Most connected entities under TEFCA will be HIPAA covered entities or business associates of covered entities, and thus will already be required to comply with the HIPAA Privacy Rule. The Common Agreement requires each non-HIPAA entity that participates in TEFCA to protect individually identifiable information that it reasonably believes is TEFCA information in substantially the same manner as HIPAA covered entities protect PHI, including having to comply with most provisions of the HIPAA Privacy Rule as if they were subject to the HIPAA Privacy Rule. Further, in some ways, the TEFCA requirements related to the Individual Access Services (IAS) exchange purpose require that IAS providers meet an even higher bar of privacy than HIPAA, including providing individuals with the right to delete their data.
                    </P>
                    <P>
                        For additional information about TEFCA requirements related to privacy, we refer readers to the most recent versions of the Common Agreement, QTF, and standard operating procedures. ONC's official website, 
                        <E T="03">HealthIT.gov</E>
                        , also provides additional information about TEFCA.
                    </P>
                    <P>
                        <E T="03">Comment.</E>
                         A commenter suggested ONC align with the approach taken by CMS in its promoting interoperability programs to explicitly name TEFCA as an optional alternative for claiming credit under the HIE Objective.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment. We are uncertain how or in what manner the commenter recommends we align the TEFCA Manner Exception with the approach CMS implemented for TEFCA participation under the promoting interoperability programs. However, as mentioned above, this comment is beyond the scope of the proposal.
                    </P>
                    <P>
                        <E T="03">Comment.</E>
                         One commenter requested ONC to consider how it can address patient portals that cannot share a full record set with a patient, and interoperability concerns that arise from portal configurations.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback. Although ONC does consider and regulate the interoperability capabilities of health IT as it relates to patient portals through the “view, download, and transmit to 3rd party” certification criterion (45 CFR 170.315(e)(1)) of the Program, this comment is beyond the scope of the proposal.
                    </P>
                    <HD SOURCE="HD2">D. Information Blocking Requests for Information</HD>
                    <HD SOURCE="HD3">1. Additional Exclusions From Offer Health IT—Request for Information</HD>
                    <P>
                        In the HTI-1 Proposed Rule (at 88 FR 23873), we sought comment on whether we should consider proposing in future rulemaking any additional exclusions from the 
                        <E T="03">
                            offer health information 
                            <PRTPAGE P="1395"/>
                            technology
                        </E>
                         or 
                        <E T="03">offer health IT</E>
                         definition proposed in § 171.102 of this proposal. We also welcomed information specific to how potential additional exclusions could be structured or balanced by other measures to mitigate risks of unintended consequences of such exclusions. We also indicated we would welcome comments on other steps ONC might consider taking to further encourage lawful donation or other subsidized provision of certified health IT to health care providers who may otherwise struggle to afford modern, interoperable health IT.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received 14 comment submissions that included comments in response to this RFI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their feedback. As noted in the HTI-1 Proposed Rule, we may use this feedback to inform a future rulemaking.
                    </P>
                    <HD SOURCE="HD3">2. Possible Additional TEFCA Reasonable and Necessary Activities—Request for Information</HD>
                    <P>
                        In the HTI-1 Proposed Rule (at 88 FR 23873 through 23874), we sought comment on whether any other particular practices that are not otherwise required by law, but are required of an individual person or entity by virtue of their status as a QHIN, Participant, or Subparticipant pursuant to the Common Agreement, pose a substantial concern or uncertainty regarding whether such practices 
                        <E T="03">could</E>
                         constitute information blocking as defined in 45 CFR 171.103. We sought comment on which particular practices the commenters believe are not covered by existing information blocking exceptions and that the commenters would advocate we assess for potential identification as reasonable and necessary activities that do not constitute information blocking as defined in 45 CFR 171.103. We also sought comment on whether and how any such identification of additional reasonable and necessary activities might pose concerns about unintended consequences for EHI access, exchange, or use by individuals or entities that are not QHINs, Participants, or Subparticipants.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received 16 comment submissions that included comments in response to this RFI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their feedback. As noted in the HTI-1 Proposed Rule, we may use this feedback to inform future rulemaking.
                    </P>
                    <HD SOURCE="HD3">3. Health IT Capabilities for Data Segmentation and User/Patient Access—Request for Information</HD>
                    <P>In the HTI-1 Proposed Rule (at 88 FR 23874 through 23875), we discussed the importance of data segmentation capabilities and a variety of situations in which segmentation of data may be required or requested, including use cases where special handling or other restriction of access, exchange, or use of particular portion(s) of a patient's EHI is required by law or consistent with an individual patient's expressed preference regarding their own or others' access to their EHI. The HTI-1 Proposed Rule included a primary and several alternative proposals for a new certification criterion specifically focused on supporting patient preferences related to their right to request restrictions on certain uses and disclosures of their PHI under the HIPAA Privacy Rule (see 45 CFR 164.522). This proposal is addressed in section III.C.10 of this final rule (see section III.C.10 for further detail).</P>
                    <P>In addition to the specific right to request a restriction on disclosure consistent with 45 CFR 164.522, there are other use cases related to patient preferences—and specific nuances within use cases—which present challenges from a technical point of view.</P>
                    <P>We sought comment to inform steps we might consider taking to improve the availability and accessibility of solutions supporting health care providers' and other information blocking actors' efforts to honor patients' expressed preferences regarding their EHI (88 FR 23874). We also specifically sought (88 FR 23875) comment on additional topics related to the capabilities of health IT products to segment data, such as experiences with the availability and utility of certified health IT products' capabilities to segment data in use cases, including, but not limited to, the illustrative examples above.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received 102 comment submissions that included comments in response to this RFI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their feedback. As noted in the HTI-1 Proposed Rule, we may use this feedback to inform a future rulemaking.
                    </P>
                    <HD SOURCE="HD1">V. Incorporation by Reference</HD>
                    <P>
                        The Office of the Federal Register has established requirements for materials (
                        <E T="03">e.g.,</E>
                         standards and implementation specifications) that agencies incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5(b)). Specifically, § 51.5(b) requires agencies to discuss, in the preamble of a final rule, the ways that the materials they incorporate by reference are reasonably available to interested parties or how it worked to make those materials reasonably available to interested parties; and summarize, in the preamble of the final rule, the material they incorporate by reference.
                    </P>
                    <P>To make the materials we intend to incorporate by reference reasonably available, we provide a uniform resource locator (URL) for the standards and implementation specifications. In many cases, these standards and implementation specifications are directly accessible through the URLs provided. In most of these instances, access to the standard or implementation specification can be gained through no-cost (monetary) participation, subscription, or membership with the applicable standards developing organization (SDO) or custodial organization. Alternatively, a copy of the standards may be viewed for free at the U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW, Washington, DC 20201. Please call (202) 690-7171 in advance to arrange inspection.</P>
                    <P>
                        The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 
                        <E T="03">et seq.</E>
                        ) and the Office of Management and Budget (OMB) Circular A-119 require the use of, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular A-119 provide exceptions to selecting only standards developed or adopted by voluntary consensus standards bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. As discussed in section III.B of this preamble, we have followed the NTTAA and OMB Circular A-119 in adopting standards and implementation specifications, including describing any exceptions in the adoption of standards and implementation specifications. Over the years of adopting standards and implementation specifications for certification, we have worked with SDOs, such as HL7, to make the standards we adopt and incorporate by reference in the 
                        <E T="04">Federal Register</E>
                        , available to interested parties. As described above, this includes making the standards and implementation specifications available through no-cost memberships and no-cost subscriptions.
                    </P>
                    <P>
                        As required by § 51.5(b), we provide summaries of the standards we have adopted and incorporate by reference in the Code of Federal Regulations. We also provide relevant information about these standards and implementation specifications throughout the preamble.
                        <PRTPAGE P="1396"/>
                    </P>
                    <P>We have organized the following standards and implementation specifications that we have adopted through this rulemaking according to the sections of the CFR in which they would be codified and cross-referenced for associated certification criteria and requirements that we have adopted.</P>
                    <HD SOURCE="HD2">Content Exchange Standards and Implementation Specifications for Exchanging Electronic Health Information—45 CFR 170.205</HD>
                    <P>
                        • 
                        <E T="03">Health Level 7 (HL7®) CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1—US Realm, June 2023, Specification Version: 4.1.1.</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">http://www.hl7.org/implement/standards/product_brief.cfm?product_id=447.</E>
                    </P>
                    <P>Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The Consolidated Clinical Document Architecture (C-CDA) Companion Guide R4.1, provides essential implementer guidance to continuously expand interoperability for clinical information shared via structured clinical notes. The guidance supplements specifications established in the Health Level Seven (HL7) CDA® R2.1 IG: C-CDA Templates for Clinical Notes. This additional guidance is intended to make implementers aware of expectations and best practices for C-CDA document exchange. The objective is to increase consistency and expand interoperability across the community of data sharing partners who utilize C-CDA for information exchange.
                    </P>
                    <P>
                        • 
                        <E T="03">HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR)—US Realm 2.1.0—STU 2 US (HL7 FHIR eCR IG), August 31, 2022.</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">https://build.fhir.org/ig/HL7/case-reporting/.</E>
                    </P>
                    <P>Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.</P>
                    <P>
                        <E T="03">Summary:</E>
                         With the adoption and maturing of Electronic Health Records (EHRs), there are opportunities to better support public health surveillance as well as to better support the delivery of relevant public health information to clinical care. Electronic Case Reporting (eCR) can provide more complete and timely case data, support disease/condition monitoring, and assist in outbreak management and control. It can also improve bidirectional communications through the delivery of public health information in the context of a patient's condition and local disease trends and by facilitating ad hoc communications, as well as reduce health care provider burden by automating the completion of legal reporting requirements. The purpose of this FHIR IG is to offer opportunities to further enable automated triggering and reporting of cases from EHRs, to ease implementation and integration, to support the acquisition of public health investigation supplemental data, and to connect public health information (
                        <E T="03">e.g.,</E>
                         guidelines) with clinical workflows. Over time, FHIR may also support the distribution of reporting rules to clinical care to better align data authorities and make broader clinical data available to public health decision support services inside the clinical care environment.
                    </P>
                    <P>
                        • 
                        <E T="03">HL7 CDA® R2 Implementation Guide: Public Health Case Report—the Electronic Initial Case Report (eICR) Release 2, STU Release 3.1—US Realm (HL7 CDA eICR IG), July 2022.</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">http://www.hl7.org/implement/standards/product_brief.cfm?product_id=436.</E>
                    </P>
                    <P>Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The purpose of this implementation guide (IG) is to specify a standard for electronic submission of electronic initial public health case reports using HL7 Version 3 Clinical Document Architecture (CDA), Release 2 format. This implementation guide specifies a standard that will allow health care providers to electronically communicate the specific data needed in initial public health case reports (required by state laws/regulations) to jurisdictional public health agencies in CDA format—an interoperable, industry-standard format.
                    </P>
                    <P>
                        • 
                        <E T="03">HL7 CDA® R2 Implementation Guide: Reportability Response, Release 1, STU Release 1.1—US Realm (HL7 CDA RR IG), July 2022.</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">https://www.hl7.org/implement/standards/product_brief.cfm?product_id=470.</E>
                    </P>
                    <P>Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The purpose of this implementation guide (IG) is to specify a standard for a response document for a public health electronic Initial Case Report (HL7 eICR all releases) using HL7 Version 3 Clinical Document Architecture (CDA), Release 2 format. Through the Reportability Response, public health seeks to support bidirectional communication with clinical care for reportable conditions in CDA format, which is an interoperable, industry-standard format.
                    </P>
                    <P>
                        • 
                        <E T="03">Reportable Conditions Trigger Codes Value Set for Electronic Case Reporting. RCTC OID: 2.16.840.1.114222.4.11.7508, Release March 29, 2022.</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">https://ecr.aimsplatform.org/ehr-implementers/triggering/.</E>
                    </P>
                    <P>Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The Reportable Condition Trigger Codes (RCTC) are a nation-wide set of standardized codes to be implemented within an electronic health record (EHR) that provide a preliminary identification of events that may be of interest to public health for electronic case reporting. The RCTC are the first step in a two-step process to determine reportability. The RCTC are single factor codes that represent any event that may be reportable to any public health agency in the United States. A second level of evaluation still must be done against jurisdiction-specific reporting regulations, to confirm whether the event is reportable and to which public health agency or agencies. The RCTC currently includes ICD 10 CM, SNOMED CT, LOINC, RxNorm, CVX, and CPT, representing condition-specific diagnoses, resulted lab tests names, lab results, lab orders for conditions reportable upon suspicion, and medications for select conditions.
                    </P>
                    <HD SOURCE="HD2">Vocabulary Standards for Representing Electronic Health Information—45 CFR 170.207</HD>
                    <P>
                        • 
                        <E T="03">HL7 Standard Code Set CVX—Vaccines Administered, dated June 15, 2022.</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">https://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cvx.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The CDC's National Center of Immunization and Respiratory Diseases (NCIRD) developed and maintains the CVX (vaccine administered) code set. It includes both active and inactive vaccines available in the US. CVX codes for inactive vaccines allow transmission of historical immunization records. When a MVX (manufacturer) code is paired with a CVX (vaccine administered) code, the specific trade named vaccine may be indicated. These codes should be used for immunization messages using HL7 Version 2.5.1.
                    </P>
                    <P>
                        • 
                        <E T="03">National Drug Code Directory (NDC)—Vaccine NDC Linker, dated July 19, 2022.</E>
                        <PRTPAGE P="1397"/>
                    </P>
                    <P>
                        URL: 
                        <E T="03">https://www2.cdc.gov/vaccines/iis/iisstandards/ndc_tableaccess.asp.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The Drug Listing Act of 1972 requires registered drug establishments to provide the FDA with a current list of all drugs manufactured, prepared, propagated, compounded, or processed by it for commercial distribution. Drug products are identified and reported using a unique, three-segment number, called the National Drug Code (NDC), which serves as the universal product identifier for drugs. This standard is limited to the NDC vaccine codes identified by CDC.
                    </P>
                    <P>
                        • 
                        <E T="03">CDC Race and Ethnicity Code Set version 1.2, (July 08, 2021).</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">https://www.cdc.gov/phin/resources/vocabulary/index.html.</E>
                    </P>
                    <P>The code set can be accessed through this link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The CDC has prepared a code set for use in coding race and ethnicity data. This code set is based on current federal standards for classifying data on race and ethnicity, specifically the minimum race and ethnicity categories defined by the U.S. Office of Management and Budget (OMB) and a more detailed set of race and ethnicity categories maintained by the U.S. Bureau of the Census (BC). The main purpose of the code set is to facilitate use of federal standards for classifying data on race and ethnicity when these data are exchanged, stored, retrieved, or analyzed in electronic form. At the same time, the code set can be applied to paper-based record systems to the extent that these systems are used to collect, maintain, and report data on race and ethnicity in accordance with current federal standards.
                    </P>
                    <P>
                        • 
                        <E T="03">Medicare Provider and Supplier Taxonomy Crosswalk, 2021.</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">https://data.cms.gov/provider-characteristics/medicare-provider-supplier-enrollment/medicare-provider-and-supplier-taxonomy-crosswalk/data/2021.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The Medicare Provider and Supplier Taxonomy Crosswalk dataset lists the providers and suppliers eligible to enroll in Medicare programs with the proper healthcare provider taxonomy code. This data includes the Medicare specialty codes, if available, provider/supplier type description, taxonomy code, and the taxonomy description. The Healthcare Provider Taxonomy Code Set is a hierarchical code set that consists of codes, descriptions, and definitions. Healthcare Provider Taxonomy Codes are designed to categorize the type, classification, and/or specialization of health care providers. The Code Set is available from the Washington Publishing Company (
                        <E T="03">https://wpc-edi.com/</E>
                        ). The Code Set is maintained by the National Uniform Claim Committee (
                        <E T="03">https://www.nucc.org/</E>
                        ).
                    </P>
                    <P>
                        • 
                        <E T="03">Public Health Data Standards Consortium Users Guide for Source of Payment Typology Code Set, December 2020, Version 9.2.</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">https://nahdo.org/sites/default/files/2020-12/SourceofPaymentTypologyUsersGuideVersion9.2December2020.pdf.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The Source of Payment Typology was developed to create a standard for reporting payer type data that will enhance the payer data classification; it is also intended for use by those collecting data or analyzing healthcare claims information. Modeled loosely after the ICD typology for classifying medical conditions, the proposed typology identifies broad Payer categories with related subcategories that are more specific. This format provides analysts with flexibility to either use payer codes at a highly detailed level or to roll up codes to broader hierarchical categories for comparative analyses across payers and locations.
                    </P>
                    <P>
                        • 
                        <E T="03">Logical Observation Identifiers Names and Codes (LOINC ®) Database Version 2.72, a universal code system for identifying laboratory and clinical observations produced by the Regenstrief Institute, Inc., February 16, 2022.</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">https://loinc.org/downloads/.</E>
                    </P>
                    <P>Access requires registration, a user account, and license agreement. There is no monetary cost for registration, a user account, and license agreement.</P>
                    <P>
                        <E T="03">Summary:</E>
                         Informed by tracking healthcare trends, evaluating concept requests, and listening to guidance from the community, this release contains new and edited concepts in Laboratory, Clinical, Survey, Document Type, and other domains. It also includes a newly streamlined release file structure for more efficient download and use.
                    </P>
                    <P>
                        • 
                        <E T="03">The Unified Code for Units of Measure, Revision 2.1, November 21, 2017.</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">https://ucum.org/ucum.html.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The Unified Code for Units of Measure is a code system intended to include all units of measures being contemporarily used in international science, engineering, and business. The purpose is to facilitate unambiguous electronic communication of quantities together with their units. The focus is on electronic communication, as opposed to communication between humans. A typical application of The Unified Code for Units of Measure are electronic data interchange (EDI) protocols, but there is nothing that prevents it from being used in other types of machine communication.
                    </P>
                    <P>
                        • 
                        <E T="03">Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, March 2022.</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">https://www.nlm.nih.gov/healthit/snomedct/us_edition.html.</E>
                    </P>
                    <P>Access requires a user account and license agreement. There is no monetary cost for a user account and license agreement.</P>
                    <P>
                        <E T="03">Summary:</E>
                         In addition to the 279 new active concepts specific to the US Edition, the March 2022 SNOMED CT US Edition also includes the SNOMED CT COVID-19 Related Content published in the January 2022 SNOMED CT International Edition. This latest version of the US Edition also includes the SNOMED CT to ICD-10-CM reference set, with over 126,000 SNOMED CT source concepts mapped to ICD-10-CM targets.
                    </P>
                    <P>
                        • 
                        <E T="03">RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, July 5, 2022, Full Update Release.</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">https://www.nlm.nih.gov/research/umls/rxnorm/docs/rxnormfiles.html.</E>
                    </P>
                    <P>Access requires a user account and license agreement. There is no monetary cost for a user account and license agreement.</P>
                    <P>
                        <E T="03">Summary:</E>
                         RxNorm, a standardized nomenclature for clinical drugs, is produced by the National Library of Medicine. RxNorm's standard identifiers and names for clinical drugs are connected to the varying names of drugs present in many different controlled vocabularies within the Unified Medical Language System (UMLS) Metathesaurus, including those in commercially available drug information sources. These connections are intended to facilitate interoperability among the computerized systems that record or process data dealing with clinical drugs.
                    </P>
                    <HD SOURCE="HD2">United States Core Data for Interoperability—45 CFR 170.213</HD>
                    <P>
                        • 
                        <E T="03">United States Core Data for Interoperability (USCDI), October 2022 Errata, Version 3 (v3).</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">https://www.healthit.gov/USCDI.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The United States Core Data for Interoperability (USCDI establishes a minimum set of data classes that are required to be interoperable nationwide and is 
                        <PRTPAGE P="1398"/>
                        designed to be expanded in an iterative and predictable way over time. Data classes listed in the USCDI are represented in a technically agnostic manner to set a foundation for broader sharing of electronic health information. ONC has established a predictable, transparent, and collaborative expansion process for USCDI based on public evaluation of previous versions and submissions by the health IT community and the public, including input from a federal advisory committee.
                    </P>
                    <HD SOURCE="HD2">Application Programming Interface Standards—45 CFR 170.215</HD>
                    <P>
                        • 
                        <E T="03">HL7 FHIR US Core Implementation Guide Version 6.1.0—STU6, June 19, 2023.</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">http://hl7.org/fhir/us/core/.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The US Core Implementation Guide is based on FHIR Version R4.0.1 and defines the minimum set of constraints on the FHIR resources to create the US Core Profiles. It also defines the minimum set of FHIR RESTful interactions for each of the US Core Profiles to access patient data. By establishing the “floor” of standards to promote interoperability and adoption through common implementation, it allows for further standards development evolution for specific uses cases.
                    </P>
                    <P>
                        • 
                        <E T="03">HL7 FHIR® SMART App Launch Implementation Guide Release 2.0.0, November 26, 2021.</E>
                    </P>
                    <P>
                        URL: 
                        <E T="03">http://hl7.org/fhir/smart-app-launch/.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This implementation guide describes a set of foundational patterns based on OAuth 2.0 for client applications to authorize, authenticate, and integrate with FHIR-based data systems.
                    </P>
                    <HD SOURCE="HD1">VI. Collection of Information Requirements</HD>
                    <P>
                        Under the Paperwork Reduction Act of 1995 (PRA), codified as amended at 44 U.S.C. 3501 
                        <E T="03">et seq.,</E>
                         agencies are required to provide a 30-day notice in the 
                        <E T="04">Federal Register</E>
                         and solicit public comment on a proposed collection of information before it is submitted to the Office of Management and Budget for review and approval. In order to fairly evaluate whether an information collection should be approved by the OMB, section 3506(c)(2)(A) of the PRA requires that we solicit comment on the following issues:
                    </P>
                    <P>1. Whether the information collection is necessary and useful to carry out the proper functions of the agency.</P>
                    <P>2. The accuracy of the agency's estimate of the information collection burden.</P>
                    <P>3. The quality, utility, and clarity of the information to be collected; and</P>
                    <P>4. Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.</P>
                    <P>Under the PRA, the time, effort, and financial resources necessary to meet the information collection requirements referenced in this section are to be considered. We solicited comment on these issues in the HTI-1 Proposed Rule (88 FR 23878 through 23880) for the matters discussed in detail below.</P>
                    <HD SOURCE="HD2">A. Independent Entity</HD>
                    <P>As stated in the HTI-1 Proposed Rule (88 FR 23847), we proposed that response submissions related to the Insights Condition and Maintenance of Certification requirements would be submitted to an independent entity on behalf of ONC, and that we intend to award a grant, contract, or other agreement to an independent entity as part of the implementation of the Insights Condition and Maintenance of Certification requirements.</P>
                    <P>For estimating potential burden, we stated that we believe the independent entity would take approximately 5 minutes to review a response submission for completeness, and approximately 30 minutes to submit the completed response submission to ONC, based on how many products a developer of certified health IT may be required to submit responses for. We also stated that we plan to minimize burden for the independent entity by automating parts of the response review and submission process via an online tool.</P>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s100,10,8,6">
                        <TTITLE>Table 3—Estimated Annualized Burden Hours for Independent Entity To Review and Submit Developer Responses to ONC per Insights Condition Requirements</TTITLE>
                        <BOXHD>
                            <CHED H="1">Code of Federal regulations section</CHED>
                            <CHED H="1">Number of independent entity</CHED>
                            <CHED H="1">Average burden hours</CHED>
                            <CHED H="1">Total</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">45 CFR 170.407(a)</ENT>
                            <ENT>1</ENT>
                            <ENT>24</ENT>
                            <ENT>24</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">45 CFR 170.407(b)</ENT>
                            <ENT>1</ENT>
                            <ENT>143</ENT>
                            <ENT>143</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Burden Hours</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT>167</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments specific to the response submissions related to the Insights Condition and Maintenance of Certification requirements that would be submitted to an independent entity on behalf of ONC.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We continue to maintain our estimated annualized burden hours for an independent entity to take approximately 5 minutes to review a response submission for completeness, and approximately 30 minutes to submit the completed response submission to ONC. We refer readers to section VII (Regulatory Impact Analysis) of this final rule for the cost estimates related to the Insights Condition.
                    </P>
                    <HD SOURCE="HD2">B. Health IT Developers</HD>
                    <P>
                        We stated in the HTI-1 Proposed Rule (88 FR 23846), developers of certified health IT would be required to submit responses associated with the Insights Condition and Maintenance of Certification requirements to an independent entity twice a year. For the purposes of estimating potential burden, we estimated 52 developers of certified health IT would be required to report on the Insights Condition. We estimated it would take approximately 21,136 to 44,900 hours on average for a developer of certified health IT to collect and report on the proposed measures within the Insights Condition and Maintenance of Certification requirements. For the purposes of estimating the total potential burden for developers of certified health IT, we estimated an average burden of 2,334,800 hours. We stated that this was crude upper bound estimate as there are multiple measures with varying complexity associated with the Insights Condition and Maintenance of Certification, and the number of developers of certified health IT required to report changes by each measure.
                        <PRTPAGE P="1399"/>
                    </P>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s100,15,15,15">
                        <TTITLE>Table 4—Estimated Annualized Total Burden Hours for Health IT Developers To Comply With the Insights Condition and Maintenance of Certification Requirements</TTITLE>
                        <BOXHD>
                            <CHED H="1">Code of Federal regulations section</CHED>
                            <CHED H="1">Number of health IT developers</CHED>
                            <CHED H="1">Average burden hours—lower bound</CHED>
                            <CHED H="1">Average burden hours—upper bound</CHED>
                        </BOXHD>
                        <ROW RUL="n,s">
                            <ENT I="01">45 CFR 170.407(a)</ENT>
                            <ENT>52</ENT>
                            <ENT>17,445</ENT>
                            <ENT>38,750</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Burden Hours</ENT>
                            <ENT/>
                            <ENT>790,806</ENT>
                            <ENT>1,767,692</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>In the HTI-1 Proposed Rule (88 FR 23797), we stated for § 170.315(b)(11)(vii)(B), health IT developers would compile documentation regarding the intervention risk management practices listed in § 170.315(b)(11)(vii)(A), and upon request from ONC, make available such detailed documentation for any Predictive DSI, as defined in § 170.102, that the certified Health IT Module enables or interfaces with. We stated that we believe ONC has the authority to conduct Direct Review consistent with § 170.580(a)(2) for any known non-conformity or where it has a reasonable belief that a non-conformity exists enabling ONC to have oversight of these requirements. The PRA, however, exempts these information collections. Specifically, 44 U.S.C. 3518(c)(1)(B)(ii) excludes collection activities during the conduct of administrative actions or investigations involving the agency against specific individuals or entities.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments specific to either collection of information from developers of health IT or our corresponding PRA determinations.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         For the first information collection, we have provided updated burden estimates above in Table 4 to reflect revisions we have finalized for the Insights Condition. Recognizing that there was some overlap for the Insights and Real World Testing Condition of Certification, we have finalized that health IT developers who were required to report for the Insights Condition could leverage relevant Insights measures for real world testing annual reporting to reduce costs. In addition, due to significant overlap we have finalized across many of the measures, we have reduced the estimated burden hours assuming there will be a 10% overlap of developing infrastructure across all measures. For a more detailed discussion and the cost estimates of these new regulatory requirements associated with the Insights Condition and Maintenance of Certification, we refer readers to section VII (Regulatory Impact Analysis) of this final rule.
                    </P>
                    <P>For the second information collection, we continue to maintain that information collected pursuant to an administrative enforcement action is not subject to the PRA under 44 U.S.C. 3518(c)(1)(B)(ii), which excludes collection activities during the conduct of administrative actions or investigations involving the agency against specific individuals or entities.</P>
                    <HD SOURCE="HD2">C. ONC-ACBs</HD>
                    <P>
                        As stated in the HTI-1 Proposed Rule (88 FR 23782), we proposed in § 170.315(b)(11)(vii)(C) that a health IT developer that attests “yes” in § 170.315(b)(11)(v)(A) submit summary information of the intervention risk management practices listed in § 170.315(b)(11)(vii)(A)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">3</E>
                        ) to its ONC-ACB via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps. To support submission of documentation, and consistent with other Principles of Proper Conduct in § 170.523(f)(1), we proposed a new Principle of Proper Conduct for documentation related to § 170.315(b)(11)(vii)(C) in § 170.523(f)(1)(xxi). In the 2015 Edition Proposed Rule (80 FR 16894), we estimated fewer than ten annual respondents for all of the regulatory “collection of information” requirements that applied to the ONC-ACBs, including those previously approved by OMB. In the 2015 Edition Final Rule (80 FR 62733), we concluded that the regulatory “collection of information” requirements for the ONC-ACBs were not subject under the implementing regulations of the PRA at 5 CFR 1320.3(c).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments specific to the new Principle of Proper Conduct for the submission of documentation in § 170.523(f)(1)(xxi).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the requirements in § 170.523(f)(1)(xxi), as proposed, which will require ONC-ACBs to ensure that developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) submit summary information of intervention risk management practices (for each Predictive DSI supplied by the health IT developer as part of its Health IT Module) via publicly accessible hyperlinks that allow any person to access the summary information directly without any preconditions or additional steps. We continue to maintain our past determinations in that we estimate less than ten annual respondents for all the regulatory “collection of information” requirements for ONC-ACBs under part 170 of title 45, including those previously approved by OMB and in this final rule, and that the regulatory “collection of information” requirements under the Program described in this section are not subject under the implementing regulations of the PRA at 5 CFR 1320.3(c). For the cost estimates of these new regulatory requirements, we refer readers to section VII (Regulatory Impact Analysis) of this final rule.
                    </P>
                    <HD SOURCE="HD1">VII. Regulatory Impact Analysis</HD>
                    <HD SOURCE="HD2">A. Statement of Need</HD>
                    <P>This final rule is necessary to meet our statutory responsibilities under the Cures Act and to advance HHS policy goals to promote interoperability and mitigate burden for health IT developers and users. Policies that could result in monetary costs for health IT developers and users include: (1) updates to ONC Certification Criteria for Health IT; (2) the Insights Condition and Maintenance of Certification requirements; and (3) policies related to information blocking.</P>
                    <P>
                        While much of this final rule's costs will fall on health IT developers who seek to certify health IT under the Program, we believe the implementation and use of ONC Certification Criteria for Health IT, compliance with the Insights Condition and Maintenance of Certification requirements (“Insights Condition”), and the provisions related to information blocking will ultimately result in significant benefits for health care providers and patients. We outline some of these benefits below. We emphasize in this regulatory impact analysis (RIA) that we believe this final rule will remove barriers to interoperability and EHI exchange, which will greatly benefit health care providers and patients.
                        <PRTPAGE P="1400"/>
                    </P>
                    <P>We note in this RIA that there were instances in which we had difficulty quantifying certain benefits due to a lack of applicable studies, data, or both. However, in such instances, we highlight the significant non-quantified benefits of our policies to advance an interoperable health system that empowers individuals to use their EHI to the fullest extent and enables health care providers and communities to deliver smarter, safer, and more efficient care.</P>
                    <HD SOURCE="HD2">B. Alternatives Considered</HD>
                    <P>If there are alternatives to our policies, we have described them within each of the sections within this RIA. In some cases, we have been unable to identify alternatives that would appropriately implement our responsibilities under the Cures Act and support interoperability. We believe our policies take the necessary steps to fulfill the mandates specified in the Public Health Service Act (PHSA), as amended by the Health Information Technology for Economic and Clinical Health (HITECH) Act and the Cures Act, in the least burdensome way. We welcomed comments on our assessment and any alternatives we should consider.</P>
                    <HD SOURCE="HD2">C. Overall Impact</HD>
                    <P>We have examined the impacts of this 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), section 1102(b) of the Social Security Act, section 202 of the Unfunded Mandates Reform Act of 1995 (March 22, 1995; Pub. L. 104-4), 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). The Executive Order 14094 entitled “Modernizing Regulatory Review” (hereinafter, the Modernizing E.O.) 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 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>A regulatory impact analysis (RIA) must be prepared for major rules with significant regulatory actions and/or with significant effects as per section 3(f)(1) ($200 million or more in any 1 year).</P>
                    <P>Based on our estimates, OMB's Office of Information and Regulatory Affairs has determined this rulemaking is significant per section 3(f)(1) as measured by the $200 million or more in any 1 year, and hence also a major rule under Subtitle E of the Small Business Regulatory Enforcement Fairness Act of 1996 (also known as the Congressional Review Act) (Pub. L. 104-121, Mar. 29, 1996).</P>
                    <HD SOURCE="HD3">a. Costs and Benefits</HD>
                    <P>
                        We have estimated the potential monetary costs and benefits of this final rule for health IT developers, health care providers, patients, and the Federal Government (
                        <E T="03">i.e.,</E>
                         ONC), and have broken those costs and benefits out by section. In accordance with Executive Order 12866, we have included the RIA summary table as Table 37.
                    </P>
                    <P>
                        Our cost calculations quantify health IT developers' time and effort to implement these policies through new development and administrative activities. We recognize that the costs developers incur as a result of these policies may be passed on to certified health IT end-users. These end-users include but are not limited to the nearly 5,000 non-federal hospitals who provide acute, inpatient care and over one million clinicians who provide outpatient care to all Americans. Official statistics show that nearly all U.S. non-federal acute care hospitals (
                        <E T="03">https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records</E>
                        ) and the vast majority of outpatient physicians use certified health IT (
                        <E T="03">https://www.healthit.gov/data/quickstats/office-based-physician-electronic-health-record-adoption</E>
                        ). These policies affect the technology that all these health care providers use.
                    </P>
                    <P>The benefits, both quantifiable and not quantifiable, articulated in this impact analysis have the potential to remove barriers to interoperability and EHI exchange for all these health care providers. Though these policies first require effort by developers of certified health IT to reflect them in their software, they must then be implemented by end-users to achieve the stated benefits—to improve healthcare delivery and the overall efficacy of the technology to document, transmit, and integrate EHI across multiple data systems.</P>
                    <P>To this end, we acknowledge that these estimated costs may not be borne solely by the developers of certified health IT and could be passed on to end-users through health IT developers' licensing, maintenance, and other operating fees and costs. We assume health IT developers may pass on up to the estimated costs of these policies, but not amounts above those estimated totals.</P>
                    <P>However, we have limited data on the fees and costs charged by health IT developers and how those fees and costs are distributed across various customer organizations. Given the ongoing nature of updates made by ONC to the Certification Program, EHR developers may have already built in the costs associated with making these updates in their existing contracts. To the extent the costs associated with the updates have not been taken into account, these costs may be passed on to end-users in different ways by developers of certified health IT and across different health care provider organization types. Large integrated healthcare systems may face different fees and other pricing than different sized or structured health care provider organizations. The incredible diversity of the healthcare system also limits our ability to accurately model how these costs could be passed on, even if there were data available to estimate how these policies might alter the pricing models and fee rates of the nearly 400 health IT developers we estimate will be impacted.</P>
                    <P>
                        What we can say with more certainty is the overall impact of these policies on the healthcare system as a whole. These policies affect the certified health IT used by the providers who give care to a vast majority of Americans. Nearly all 
                        <PRTPAGE P="1401"/>
                        emergency room visits, hospital stays, and regular check-ups are documented and managed using certified health IT. These policies affect the interoperability of EHI for these care events and patients' electronic access to their health information. Certified health IT is now a nearly ubiquitous part of U.S. healthcare, and the costs and benefits estimated here encompass the widespread use of these technologies and their impact on all facets of care.
                    </P>
                    <P>Overall, it is highly speculative to quantify benefits associated with the new technical requirements and standards for certification criteria we have adopted in this final rule. Emerging technologies may be used in ways not originally predicted. For example, ONC helped support the development of SMART on FHIR, which defines a process for an application to securely request access to data, and then receive and use that data. ONC could not have predicted the scale this technical approach has already achieved. Not only is it used to support major EHR products, but is also leveraged, for example, by Apple to connect its Health® App to hundreds of healthcare systems and for apps to launch on the Microsoft Azure® product. It is also speculative to quantify benefits for specific groups because benefits associated with many of ONC's policies, which advance interoperability, don't necessarily accrue to parties making the investments in developing and implementing the technologies. Benefits related to interoperability are spread across the healthcare ecosystem and can be considered a societal benefit. We have sought to describe benefits for each of the specific policies, and we welcomed comments on how to quantify these benefits across a variety of interested parties.</P>
                    <P>
                        We note that we have rounded all estimates to the nearest dollar and that all estimates are expressed in 2022 dollars as it is the most recent data available to address all cost and benefit estimates consistently. The wages used to derive the cost estimates are from the May 2022 National Occupational Employment and Wage Estimates reported by the U.S. Bureau of Labor Statistics.
                        <SU>263</SU>
                        <FTREF/>
                         We also note that estimates presented in the following “Employee Assumptions and Hourly Wage,” “Quantifying the Estimated Number of Health IT Developers and Products,” and “Number of End Users that Might Be Impacted by ONC's Proposed Regulations” sections are used throughout this RIA.
                    </P>
                    <FTNT>
                        <P>
                            <SU>263</SU>
                             May 2021 National Occupational Employment and Wage Estimates, United States. U.S. Bureau of Labor Statistics. 
                            <E T="03">https://www.bls.gov/oes/current/oes_nat.htm.</E>
                        </P>
                    </FTNT>
                    <P>For policies where research supported direct estimates of impact, we estimated the benefits. For policies where no such research was identified to be available, we developed estimates based on a reasonable proxy.</P>
                    <P>
                        We note that interoperability can positively impact patient safety, efficacy, care coordination, and improve healthcare processes and other health-related outcomes.
                        <SU>264</SU>
                        <FTREF/>
                         However, achieving interoperability is a function of a number of factors including the capability of the technology used by health care providers. Therefore, to assess the benefits of our policies, we must first consider how to assess their respective effects on interoperability holding other factors constant.
                    </P>
                    <FTNT>
                        <P>
                            <SU>264</SU>
                             Nir Menachemi, Saurabh Rahurkar, Christopher A Harle, Joshua R Vest, The benefits of health information exchange: an updated systematic review, 
                            <E T="03">Journal of the American Medical Informatics Association,</E>
                             Volume 25, Issue 9, September 2018, Pages 1259-1265, 
                            <E T="03">https://doi.org/10.1093/jamia/ocy035.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Employee Assumptions and Hourly Wage</HD>
                    <P>
                        We have made employee assumptions about the level of expertise needed to complete the requirements in this section. Unless indicated otherwise, for wage calculations for federal employees and ONC-ACBs, we have correlated the employee's expertise with the corresponding grade and step of an employee classified under the General Schedule (GS) Federal Salary Classification, relying on the associated employee hourly rates for the Washington, DC, locality pay area as published by the Office of Personnel Management for 2022.
                        <SU>265</SU>
                        <FTREF/>
                         We have assumed that other indirect costs (including benefits) are equal to 100% of pre-tax wages. Therefore, we have doubled the employee's hourly wage to account for other indirect costs. We have concluded that a 100% expenditure on benefits and overhead is an appropriate estimate based on research conducted by HHS.
                        <SU>266</SU>
                        <FTREF/>
                         Unless otherwise noted, we have consistently used the May 2022 National Occupational Employment and Wage Estimates reported by the U.S. Bureau of Labor Statistics (BLS) to calculate private sector employee wage estimates (
                        <E T="03">e.g.,</E>
                         health IT developers, health care providers, HINs, attorneys, etc.), as we believe BLS provides the most accurate and comprehensive wage data for private sector positions.
                        <SU>267</SU>
                        <FTREF/>
                         Just as with the General Schedule Federal Salary Classification calculations, we have assumed that other indirect costs (including benefits) are equal to 100% of pre-tax wages. We welcomed comments on our methodology for estimating labor costs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>265</SU>
                             Office of Personnel and Management. 2022 General Schedule (GS) Locality Pay Tables 
                            <E T="03">https://www.opm.gov/policy-data-oversight/pay-leave/salaries-wages/2022/general-schedule/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>266</SU>
                             
                            <E T="03">See</E>
                             U.S. Department of Health and Human Services, Office of the Assistant Secretary for Planning and Evaluation (ASPE), 
                            <E T="03">Guidelines for Regulatory Impact Analysis,</E>
                             at 28-30 (2016), available at 
                            <E T="03">https://aspe.hhs.gov/reports/guidelines-regulatory-impact-analysis.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>267</SU>
                             May 2021 National Occupational Employment and Wage Estimates, United States. U.S. Bureau of Labor Statistics. 
                            <E T="03">https://www.bls.gov/oes/current/oes_nat.htm.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Quantifying the Estimated Number of Health IT Developers and Products</HD>
                    <P>In this section, we describe the methodology used to assess the potential impact of new certification requirements on the availability of certified products in the health IT market. This analysis is based on the number of health IT developers that certified Health IT Modules for the 2015 Edition and the estimated number of developers that will participate in the future and the number of products these developers will certify.</P>
                    <P>
                        These estimations are based on observed and expected conformance to 2015 Edition Cures Update requirements, market consolidation, industry trends and business decisions by participating developers, and other voluntary and involuntary withdrawals from the Program. In Table 5 below, we quantify the number of participating developers and certified products for the 2011 Edition, 2014 Edition, and 2015 Edition. We found that the number of health IT developers certifying products between the 2011 Edition and 2014 Edition decreased by 22.1% and the number of certified products available decreased by 23.2%. Furthermore, we found that between the 2014 Edition and 2015 Edition the number of participating developers and certified products decreased by 38.3% and 33.9%.
                        <PRTPAGE P="1402"/>
                    </P>
                    <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s100,12,12,10,12,10">
                        <TTITLE>Table 5—Number of Developers and Products for the 2011 Edition, 2014 Edition, and 2015 Edition</TTITLE>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="1">2011 Edition</CHED>
                            <CHED H="1">2014 Edition</CHED>
                            <CHED H="1">
                                Change
                                <LI>(%)</LI>
                            </CHED>
                            <CHED H="1">2015 Edition</CHED>
                            <CHED H="1">
                                Change
                                <LI>(%)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Participating Health IT Developers</ENT>
                            <ENT>1,017</ENT>
                            <ENT>792</ENT>
                            <ENT>−22.1</ENT>
                            <ENT>489</ENT>
                            <ENT>−38.3</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Certified Products Available</ENT>
                            <ENT>1,408</ENT>
                            <ENT>1,081</ENT>
                            <ENT>−23.2</ENT>
                            <ENT>714</ENT>
                            <ENT>−33.9</ENT>
                        </ROW>
                        <TNOTE>
                            <E T="02">Note:</E>
                             Counts for 2015 Edition reflect all certificates through 2021. These counts include certificates that are active and withdrawn.
                        </TNOTE>
                    </GPOTABLE>
                    <P>We recognize that certification for 2015 Edition and 2015 Edition Cures Update is ongoing and the number of health IT developers certifying products to the 2015 Edition and 2015 Edition Cures Update is subject to change. The figures for 2015 Edition in Table 5 reflect certifications through 2021 to provide a fixed point for analysis. We have found it prudent to use certification data that represent entire calendar years, and not to use certification stats mid-year. Therefore, 2015 Edition counts do not account for all certificates as of the publication of this rulemaking.</P>
                    <P>These figures give us insight into how participation in the Program and certification for individual certification editions has changed over time—the effect of both market and regulatory forces. Given historical trends and the asymmetric costs faced by developers of certified technology with large and small client bases, we must consider the effect of certification requirements going into effect and adopted in this rulemaking on future participation in the Program to make our best estimates of the cost and benefits of this rulemaking.</P>
                    <P>Our estimates of health IT developers and certified products specifically factor in a reduction in Program participation due to non-conformance with the 2015 Edition Cures Update criterion, “standardized API for patient and population services (“standardized API criterion”). The criterion replaces the 2015 Edition criterion, “application access—data category request” (“data category request criterion”). The data category request criterion required no content and exchange standard, although ONC communicated its intent to support a standard for future rulemaking and did encourage the use of the FHIR standard to meet criterion requirements. The new standardized API criterion does require FHIR as a content and exchange standard. Products that certified the data category request criterion must certify the standardized API criterion by December 31, 2022.</P>
                    <P>
                        In the RIA for the ONC Cures Act Final Rule, we estimated that certified API products that did not support FHIR and must do so to meet regulatory requirements may face up to $1.9 million in development and other labor and maintenance costs to develop this technology for the first time (85 FR 25921). In 2018 
                        <SU>268</SU>
                        <FTREF/>
                         and 2021 
                        <SU>269</SU>
                        <FTREF/>
                         analyses, we found that support for FHIR was not common among 2015 Edition certified API products, although health IT market leaders predominantly supported the standard and used it as the content and exchange standard for their certified API technology. As of the end of 2021, our analysis of certification data found that approximately 60% of certified API developers did not support FHIR as part of their certified API technology. Considering this variation in support for the standard under the 2015 Edition and the costs faced by developers of certified health IT to meet this requirement, we expect some attrition from the Program.
                    </P>
                    <FTNT>
                        <P>
                            <SU>268</SU>
                             
                            <E T="03">https://www.healthit.gov/buzz-blog/interoperability/heat-wave-the-u-s-is-poised-to-catch-fhir-in-2019.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>269</SU>
                             
                            <E T="03">https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-2019.</E>
                        </P>
                    </FTNT>
                    <P>Our model assumes that 1 in 4 certified API developers that do not currently support FHIR will not certify the standardized API criterion and withdraw their certificates. This is based on available market data and the historical trend of developers with small client bases to exit the Program as program requirements and their costs increase. Our estimates may change as health IT developers meet 2015 Edition Cures Update requirements and developers certify the standardized API criterion.</P>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,18,16">
                        <TTITLE>Table 6—Estimated Number of Developers and Products</TTITLE>
                        <BOXHD>
                            <CHED H="1">Scenario</CHED>
                            <CHED H="1">
                                Estimated number of
                                <LI>health IT developers</LI>
                            </CHED>
                            <CHED H="1">
                                Estimated number
                                <LI>of products</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">All Products—End of 2021</ENT>
                            <ENT>414</ENT>
                            <ENT>569</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">All Products—Modeled Attrition</ENT>
                            <ENT>368</ENT>
                            <ENT>502</ENT>
                        </ROW>
                        <TNOTE>
                            <E T="02">Note:</E>
                             End of 2021 counts reflect active products only.
                        </TNOTE>
                    </GPOTABLE>
                    <P>At the end of 2021, 414 health IT developers certified 569 products with active certificates for the 2015 Edition or 2015 Edition Cures Update. This is a 15% decrease in the number of health IT developers and a 20% decrease in 2015 Edition certified products, overall. Using our model of certification for the standard API criterion, we estimate an additional 11% decrease in the number of health IT developers and a 12% decrease in the number of certified products. For this RIA, we will use 368 as the number of health IT developers and 502 as the number of certified health IT products impacted by this rulemaking.</P>
                    <HD SOURCE="HD3">Number of End Users That Might Be Impacted by ONC's Finalized Regulations</HD>
                    <P>
                        For the purpose of this analysis, the population of end users impacted are the number of health care providers that possess certified health IT. Due to data limitations, our analysis is based on the number of hospitals and clinicians who participate in Medicare and who may be required to use certified health IT to participate in various CMS programs, inclusive of those providers who received incentive payments to adopt certified health IT as part of the Medicare EHR Incentive Program (now known as the Promoting Interoperability Program).
                        <PRTPAGE P="1403"/>
                    </P>
                    <P>
                        One limitation of this approach is that we are unable to account for the impact of our provisions on users of health IT that were ineligible or did not participate in the CMS EHR Incentive Programs or current Medicare performance programs (
                        <E T="03">e.g.,</E>
                         Promoting Interoperability and Advanced Payment Model (APM) programs). For example, in 2017, 78 percent of home health agencies and 66 percent of skilled nursing facilities reported adopting an EHR (
                        <E T="03">https://www.healthit.gov/data/data-briefs/electronic-health-record-adoption-and-interoperability-among-us-skilled-nursing</E>
                        ). Nearly half of these facilities reported engaging aspects of health information exchange. However, we are unable to quantify, specifically the use of certified health IT products, among these provider types.
                    </P>
                    <P>
                        Despite these limitations, these Medicare program participants represent an adequate sample on which to base our estimates. An analysis of the CMS Provider of Services file for Hospitals (
                        <E T="03">https://data.cms.gov/provider-characteristics/hospitals-and-other-facilities/provider-of-services-file-hospital-non-hospital-facilities</E>
                        ) and CMS National Downloadable File of Doctors and Clinicians (
                        <E T="03">https://data.cms.gov/provider-data/dataset/mj5m-pzi6</E>
                        ) provides a current accounting of Medicare-participating hospitals and practice locations. In total, we estimated about 4,800 non-federal acute care hospitals from the Provider of Services file and 1.25 million clinicians (including doctors and advanced nurse practitioners) across over 350,000 practice locations. If we assume that 96% of these hospitals and 80% of these practice locations use certified health IT, as survey data estimate, approximately 4,600 hospitals and 283,000 practice locations may face some passed-on costs from these requirements.
                    </P>
                    <P>We understand there will likely not be a proportional impact of these costs across all health care providers. We can assume a hospital will face different costs than a physician practice, and no two hospitals will face the same costs, as those costs may vary based upon various characteristics, including but not limited to: staff size, patient volume, and ownership. The same is true for individual clinical practices, for which costs may vary across the same characteristics as hospitals. However, given our limited data, our approach to model pass-through costs onto health care providers assumes that hospitals face the same average costs and that they face a higher average cost per site than an individual clinical practice. Furthermore, we assume that clinical practices face the same average costs and lower average costs per site than the average hospital.</P>
                    <P>
                        Based upon our prior modeling work for the ONC Cures Act Final Rule (
                        <E T="03">https://www.federalregister.gov/documents/2020/05/01/2020-07419/21st-century-cures-act-interoperability-information-blocking-and-the-onc-health-it-certification</E>
                        ), we assume that one-third of estimated costs will be passed on to hospitals and the remaining amount on to clinician practices. Table 7 shows an assumed distribution of the costs across technology users. The cost to any one hospital or practice is small compared to the cost as a whole. The average hospital user of certified health IT could be expected to face up to $65,217 in average additional costs associated with implementing technology that adopt these policies. The average clinician practice site could be expected to face up to $2,170 in average additional costs associated with implementing technology that adopt these policies. These are considered pass-through costs incurred by the health IT developer to adopt these policies and not additional costs exogenous to health IT developer efforts to adopt and engineer these policies into their certified health IT.
                    </P>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s100,12,12,12">
                        <TTITLE>Table 7—Model of Cost Distribution Based on Estimated Number of Hospitals and Clinical Practices With Certified Health IT</TTITLE>
                        <BOXHD>
                            <CHED H="1">Health care provider</CHED>
                            <CHED H="1">Est. count</CHED>
                            <CHED H="1">
                                Est. $ per
                                <LI>provider</LI>
                            </CHED>
                            <CHED H="1">
                                Total $ cost 
                                <LI>(m)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Hospitals</ENT>
                            <ENT>4,600</ENT>
                            <ENT>65,217</ENT>
                            <ENT>300</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Clinical Practices</ENT>
                            <ENT>283,000</ENT>
                            <ENT>2,170</ENT>
                            <ENT>614</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">All</ENT>
                            <ENT>287,600</ENT>
                            <ENT>3,178</ENT>
                            <ENT>914</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>These costs are not expected to be borne at once. Requirements from this finalized rulemaking may be implemented over several years, so in some cases an individual hospital or clinician's share of pass-through costs from their health IT developer may be distributed over one or more years. One issue to reiterate is that some of these costs may have already been incorporated within existing contracts and thus it is possible that the actual additional costs experienced by hospitals and clinicians may be lower than what is estimated. We do not have insights into proprietary contracts between EHR developers and their clients, and thus cannot speculate the extent to which the estimated additional costs will be passed on to their clients.</P>
                    <P>It's unknown if the estimated benefits will have the same distribution. A single clinician may not benefit the same as a single hospital, nor will one hospital benefit the same as another. However, given the same constraints to model costs across different provider types, we must assume a similar distribution for benefits as we propose for costs.</P>
                    <HD SOURCE="HD3">General Comments on the RIA</HD>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters were generally concerned with unmeasured costs on entities beyond developers of certified health IT, including public health authorities, health care providers, and patients, noting that the proposed regulations have effects beyond developers of certified health IT.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments and understand concerns about the broader overall downstream impact of the proposed rulemaking on entities beyond developers of certified health IT, which are specifically regulated by ONC authorities. The impact analysis measures the estimated costs for developers of certified health IT to meet the proposed new Certification Program requirements—for example, to develop or modify the technical functionality of their certified health IT or adopt a new standard or standard version. These are the expected direct costs of the proposals on developers of certified health IT. However, we recognize that developers of certified health IT are largely private businesses who operate in a competitive marketplace and that they may not bear all costs to meet these requirements. We include in the “Costs and Benefits” section of the Regulatory Impact Analysis the estimated impact on certified health IT end users. In this case, health care providers, such as 
                        <PRTPAGE P="1404"/>
                        hospitals and clinicians. We believe these estimates provide a general, but not necessarily comprehensive, understanding of the possible pass-through costs borne by users of certified health IT.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters provided suggestions to broaden the scope and depth of the regulatory impact analysis, with specific recommendations to include patient-level measures.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' thoughtful suggestions to build upon the proposed regulatory impact analysis, however, we're confident that the impact analysis provides the correct measurement of quantifiable costs and benefits. Though patient-level impacts are inherent to technology use, given the interconnectedness of healthcare, we believe that patient impacts are more directly tied to the implementation of the technology and not to its development and sale. It is hard to predict the effect on patient outcomes of one unique software technology from another, given that developers may choose to differentiate their product offerings to provide choices and competitive options to their customers. Furthermore, how the technology end-user, here defined as the health care provider, chooses to use the technology can affect outcomes for patient care, exogenous to the requirements that must be met by the developers of certified health IT, as part of Certification Program participation. Disentangling or singling out differential impacts of how technology is used and how it was designed or developed to be used is difficult to do and out of scope for this impact analysis.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concerns about the total costs measured and limited quantified benefits for this proposed rulemaking and the broader impact of these costs on end-users, who must adopt, learn, and use new versions of certified health IT.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We understand commenters' concerns about the estimated cost amounts for the proposed rulemaking and acknowledge the limited quantifiable benefits for some of these proposals. The ONC Health IT Certification Program, although voluntary, attracts participation from hundreds of developers who certify hundreds of health IT products. The impact analysis assesses the expected costs and benefits across all these developers and products. The high rates of certified health IT use further show the expansive market for health IT. In the “Costs and Benefits” section of the Regulatory Impact Analysis, we estimate the expected costs on certified health IT end-users, here defined as the health care provider. When costs are distributed across these end users, we see the expected average costs passed on to individual health care providers. We recognize the hardships faced by health care providers to finance technology upgrades and pay for new software versions that incorporate the final rule's updates. We believe the benefits from interoperability improvements, transparency, patient access, and increased data sharing outweigh those costs.
                    </P>
                    <HD SOURCE="HD3">“The ONC Certification Criteria for Health IT” and Discontinuing Year Themed “Editions”</HD>
                    <P>As discussed in section III.A of this preamble, we proposed to rename § 170.315 as the “ONC Certification Criteria for Health IT” and replace all references throughout 45 CFR part 170 to the “2015 Edition” with this new description (this would impact §§  170.102, 170.405, 170.406, 170.523, 170.524, and 170.550).</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This policy is not intended to place additional burden on developers of certified health IT and does not require new development or implementation. We expect the costs associated with attesting to these criteria to be de minimis because we do not expect any additional effort on the part of health IT developers.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>Maintaining a single set of “ONC Certification Criteria for Health IT” will create more stability for the health IT community and Program partners and make it easier for developers of certified health IT to maintain their product certificates over time. For example, when new rules are released, unchanged certification criteria will remain exactly as they are, rather than being placed in a new CFR section and requiring health IT developers to seek an updated certificate attributed to the new CFR section.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments on this impact analysis.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the impact analysis as proposed.
                    </P>
                    <HD SOURCE="HD3">United States Core Data for Interoperability Version 3 (USCDI v3)</HD>
                    <P>As discussed in section III.C.1 of this preamble, we have finalized to update the USCDI standard in § 170.213 by adding USCDI v3 and by establishing an expiration date for USCDI v1 (July 2020 Errata) on January 1, 2026, for purposes of the Program. We have finalized to add USCDI v3 in § 170.213(b) and incorporate it by reference in § 170.299. We have finalized to codify the existing reference to USCDI v1 (July 2020 Errata) in § 170.213(a). We have finalized that as of January 1, 2026, any Health IT Modules seeking certification for criteria referencing § 170.213 would need to be capable of exchanging the data classes and data elements that comprise USCDI v3. Additionally, once the USCDI standard in § 170.213 is updated to include USCDI v3, we have finalized that in order for previously certified Health IT Modules to maintain certification, health IT developers would be required to update their certified Health IT Modules to be capable of exchanging the data classes and data elements that comprise USCDI v3 for all certification criteria referencing § 170.213 by December 31, 2025. USCDI, via cross-reference to § 170.213, is currently referenced in the following criteria, each of which would refer to USCDI v1 and USCDI v3 until December 31, 2025 and only to USCDI v3 thereafter:</P>
                    <P>
                        • “Care coordination—transitions of care—create” (§ 170.315(b)(1)(iii)(A)(
                        <E T="03">1</E>
                        )).
                    </P>
                    <P>
                        • “Care coordination—clinical information reconciliation and incorporation—reconciliation” (§ 170.315(b)(2)(iii)(D)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">3</E>
                        ));
                    </P>
                    <P>
                        • “Patient engagement—view, download, and transmit to 3rd party—view” (§ 170.315(e)(1)(i)(A)(
                        <E T="03">1</E>
                        )).
                    </P>
                    <P>• “Design and performance—consolidated CDA creation performance” (§ 170.315(g)(6)(i)(A)).</P>
                    <P>
                        • “Design and performance—application access—all data request—functional requirements” (§ 170.315(g)(9)(i)(A)(
                        <E T="03">1</E>
                        )); and
                    </P>
                    <P>• “Design and performance—standardized API for patient and population services—data response” (§ 170.315(g)(10)(i)(A) and (B)).</P>
                    <P>We note that § 170.315(f)(5) also currently references § 170.213. However, we have finalized to rely on specific implementation guides for this certification criterion, rather than referencing § 170.213. Health IT Modules certified to § 170.315(f)(5) are no longer required to support USCDI, as finalized by this rule.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>
                        The USCDI v3 adds five new data classes and 46 new data elements that were not in USCDI v1. This will require updates to the Consolidated Clinical Document Architecture (C-CDA) standard, the FHIR US Core Implementation Guide, and updates to the criteria listed above. We have estimated the cost to health IT developers to add support for the additional data classes and data 
                        <PRTPAGE P="1405"/>
                        elements in USCDI v3 in C-CDA, and to make the necessary updates to the affected certification criteria. These estimates are detailed in Table 8 below and are based on the following assumptions:
                    </P>
                    <P>1. Health IT developers will experience the assumed average costs of labor and data model use. Table 8 shows the estimated labor costs per product for a health IT developer to develop support for the additional data elements and data classes in USCDI v3 for each affected certification criteria. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will incur, on average, the costs noted in Table 8.</P>
                    <P>2. We estimate that 346 products certified by 269 developers will be affected. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.</P>
                    <P>We estimate that, in total, 368 health IT developers will certify 502 health IT products impacted by this policy. However, not all these developers and products certify USCDI applicable criteria and need to meet the USCDI update requirements. As of the end of 2021, 73% of developers and 69% of products certified to one of the USCDI applicable criteria, listed above. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the USCDI updates. In Table 9, we also applied separate modifiers for individual criteria, calculated from an analysis of certificates through 2021. This allows us to assess USCDI update costs more accurately for individual criterion.</P>
                    <P>3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91. As noted previously, we have assumed that other indirect costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including other indirect costs is $127.82.</P>
                    <GPOTABLE COLS="5" OPTS="L2,nj,p7,7/8,i1" CDEF="s50,r60,6,6,r60">
                        <TTITLE>Table 8—Costs to Health IT Developers To Develop Support for the Additional USCDI Data Elements in Affected Certification Criteria</TTITLE>
                        <BOXHD>
                            <CHED H="1">Tasks</CHED>
                            <CHED H="1">Details</CHED>
                            <CHED H="1">Lower bound hours</CHED>
                            <CHED H="1">Upper bound hours</CHED>
                            <CHED H="1">Remarks</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Update C-CDA creation</ENT>
                            <ENT>New development to support USCDI v2 and v3 updates and changes to data classes and constituent data elements for C-CDA and C-CDA 2.1 Companion Guide</ENT>
                            <ENT>1,800</ENT>
                            <ENT>3,600</ENT>
                            <ENT>(1) Lower bound assumes health IT product was voluntarily updated through the ONC Standards Version Advancement Process (SVAP) and USCDIv2 data elements are incorporated in the certified product. (2) Upper bound assumes certified product conforms only to USCDIv1 and needs to be updated to fully conform with USCDIv3.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                § 170.315(b)(1)(iii)(A)(
                                <E T="03">1</E>
                                ) Care coordination—Transitions of care—Create
                            </ENT>
                            <ENT>New development to support USCDI v2 and v3 updates and changes to data classes and constituent data elements for C-CDA and C-CDA 2.1 Companion Guide</ENT>
                            <ENT>200</ENT>
                            <ENT>600</ENT>
                            <ENT>Necessary updates to health IT to support the new data classes and data elements to meet the criteria requirements.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                § 170.315(b)(2)(iii)(D)(
                                <E T="03">1</E>
                                ) through (
                                <E T="03">3</E>
                                ) Care coordination—Clinical information reconciliation and incorporation—Reconciliation
                            </ENT>
                            <ENT>New development to support USCDI v2 and v3 updates and changes to data classes and constituent data elements for C-CDA and C-CDA 2.1 Companion Guide</ENT>
                            <ENT>200</ENT>
                            <ENT>600</ENT>
                            <ENT>Necessary updates to health IT to support the new data classes and data elements to meet the criteria requirements.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                § 170.315(e)(1)(i)(A)(
                                <E T="03">1</E>
                                ) Patient engagement—View, download, and transmit to 3rd party—View
                            </ENT>
                            <ENT>New development to support USCDI v2 and v3 updates and changes to data classes and constituent data elements for C-CDA and C-CDA 2.1 Companion Guide</ENT>
                            <ENT>200</ENT>
                            <ENT>600</ENT>
                            <ENT>Necessary updates to health IT to support the new data classes and data elements to meet the criteria requirements.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(g)(6)(i) Design and performance—Consolidated CDA creation performance</ENT>
                            <ENT>New development to support USCDI v2 and v3 updates and changes to data classes and constituent data elements for C-CDA and C-CDA 2.1 Companion Guide</ENT>
                            <ENT>200</ENT>
                            <ENT>600</ENT>
                            <ENT>Necessary updates to health IT to support the new data classes and data elements to meet the criteria requirements.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                § 170.315(g)(9)(i)(A)(
                                <E T="03">1</E>
                                ) Design and performance—Application access—all data request—Functional requirements
                            </ENT>
                            <ENT>New development to support USCDI v2 and v3 updates and changes to data classes and constituent data elements for C-CDA and C-CDA 2.1 Companion Guide</ENT>
                            <ENT>200</ENT>
                            <ENT>600</ENT>
                            <ENT>Necessary updates to health IT to support the new data classes and data elements to meet the criteria requirements.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(g)(10)(i)(A) and (B) Design and performance—Standardized API for patient and population services—Data response</ENT>
                            <ENT>New development to support USCDI v2 and v3 updates and changes to data classes and constituent data elements for C-CDA and C-CDA 2.1 Companion Guide</ENT>
                            <ENT>200</ENT>
                            <ENT>600</ENT>
                            <ENT>Necessary updates to health IT to support the new data classes and data elements to meet the requirements.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s100,12,12,12">
                        <TTITLE>Table 9—Total Cost To Develop Support for the Additional USCDI Data Elements in Affected Certification Criteria </TTITLE>
                        <TDESC>[2022 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Tasks</CHED>
                            <CHED H="1">Estimated number of products</CHED>
                            <CHED H="1">Estimated cost</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Update C-CDA creation</ENT>
                            <ENT>346</ENT>
                            <ENT>$79,718,400</ENT>
                            <ENT>$159,436,800</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Updates to § 170.315(b)(1)</ENT>
                            <ENT>281</ENT>
                            <ENT>7,193,600</ENT>
                            <ENT>21,580,800</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Updates to § 170.315(b)(2)</ENT>
                            <ENT>261</ENT>
                            <ENT>6,681,600</ENT>
                            <ENT>20,044,800</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Updates to § 170.315(e)(1)</ENT>
                            <ENT>246</ENT>
                            <ENT>6,297,600</ENT>
                            <ENT>18,892,800</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Updates to § 170.315(g)(6)</ENT>
                            <ENT>341</ENT>
                            <ENT>8,729,600</ENT>
                            <ENT>26,188,800</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Updates to § 170.315(g)(9)</ENT>
                            <ENT>276</ENT>
                            <ENT>7,065,600</ENT>
                            <ENT>21,196,800</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Updates to § 170.15(g)(10)</ENT>
                            <ENT>276</ENT>
                            <ENT>7,065,600</ENT>
                            <ENT>21,196,800</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="1406"/>
                            <ENT I="03">Total Cost</ENT>
                            <ENT>346</ENT>
                            <ENT>122,752,000</ENT>
                            <ENT>288,537,600</ENT>
                        </ROW>
                        <TNOTE>
                            <E T="02">Notes:</E>
                             The number of estimated products that certify applicable criteria vary. We estimated separate modifiers for each certification criterion to estimate the number of products impacted by the USCDI updates. Estimates reflect the percent of all products that certify a criterion through 2021, except. Modifiers: (b)(1): 56%; (b)(2): 52%; (e)(1): 49%; (g)(6): 68%; (g)(9): 55%. This estimate is subject to change.
                        </TNOTE>
                    </GPOTABLE>
                    <P>The cost to a health IT developer to develop support for the additional USCDI data classes and elements vary by the number of applicable criteria certified for a Health IT Module. On average, the cost to update C-CDA creation to support the additional USCDI data elements range from $230,400 to $460,800 per product. The cost to make updates to individual criteria to support the new data classes and elements range from $25,600 to $76,800 per product. Therefore, assuming 346 products overall and a labor rate of $128 per hour, we estimate that the total cost to all health IT developers will, on average, range from $123 million to $289 million. This will be a one-time cost to developers per product that is certified to the specified certification criteria and will not be perpetual.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        We believe this policy will benefit health care providers, patients, and the industry collectively. The USCDI comprises a core set of structured and unstructured data needed to support patient care and facilitate patient access to health information using health IT; establishes a consistent baseline of harmonized data elements that can be broadly reused across use cases, including those outside of patient care and patient access; and will expand over time via a predictable, transparent, and collaborative process, weighing both anticipated benefits and industry-wide impacts. In Standards Bulletin 2022-2,
                        <SU>270</SU>
                        <FTREF/>
                         we noted that based on these principles and the established prioritization criteria, USCDI v3 contains data elements whose collection and exchange promote equity, reduce disparities, and support public health data interoperability as discussed in Standards Bulletin 2021-3,
                        <SU>271</SU>
                        <FTREF/>
                         where we highlighted that the collection, access, use, and reporting of SDOH as well as sexual orientation and gender identity data can help identify and address differences in health equity and improve health outcomes at an individual and population level. The additional data elements in USCDI v3 expand the baseline set of data available for health information exchange and thus provide more comprehensive health data for both providers and patients. We expect the resulting improvements to interoperable exchange of health information to significantly benefit providers and patients and improve the quality of healthcare provided. In addition, we believe the increased availability of the additional data elements in USCDI v3 as interoperable structured data will facilitate improvements in the efficiency, accuracy, and timeliness of public health reporting, quality measurement, health care operations, and clinical research. However, we are not aware of an approach for quantifying these benefits and welcomed comments on potential approaches to quantifying these benefits.
                    </P>
                    <FTNT>
                        <P>
                            <SU>270</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2022-07/Standards_Bulletin_2022-2.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>271</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2021-07/Standards_Bulletin_2021-3.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments regarding the impact analysis for required adoption of USCDI v3 by applicable developers of certified health IT.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The final impact analysis is consistent with the proposed rulemaking. Cost estimates were updated to reflect wages of software developers as of 2022.
                    </P>
                    <HD SOURCE="HD3">Electronic Case Reporting</HD>
                    <P>In section III.C.4 of this preamble, we discuss the finalized updates to the 2015 Edition certification criterion for “transmission to public health agencies—electronic case reporting” that would require developers of certified health IT to adopt specific electronic standards to support functional requirements that were previously adopted as part of the § 170.315(f)(5) certification criterion. We have finalized as proposed that Health IT Modules certified to this criterion must enable a user to: (i) create an electronic initial case report (eICR) according to at least the Health Level Seven (HL7) Clinical Document Architecture (CDA) eICR implementation guide (IG) or the eICR profiles defined in the HL7 Fast Health Interoperability Resources (FHIR) eCR IG and (ii) consume and process a reportability response (RR) according to at least the HL7 CDA RR IG or the RR profiles defined in the HL7 FHIR eCR IG. For the standards-based requirements in § 170.315(f)(5)(i) through (ii), we have finalized as proposed that Health IT Modules support all “mandatory” and “must support” data elements as applicable in the respective implementation guides (IGs). We have also finalized as proposed that Health IT Modules support the use of a version of the Reportable Conditions Trigger Code (RCTC) value set in § 170.315(f)(5)(1)(B) for determining potential case reportability.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs of meeting the requirements in the updated “transmission to public health agencies—electronic case reporting” criterion. The cost estimates are based on the following assumptions:</P>
                    <P>
                        • 
                        <E T="03">Health IT developers will experience the assumed average costs of labor and data model use.</E>
                         Tables 10-11 show the estimated labor costs per product for a health IT developer to meet the requirements in the eCR certification criterion. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will, on average, incur the costs noted in the tables below.
                    </P>
                    <P>
                        • 
                        <E T="03">The number of products that will update to the new eCR criterion is estimated based on the total number of currently certified products plus the number of new products we expect to certify to the eCR criterion.</E>
                         Both estimates are adjusted for attrition. As of 2021, 54 developers certified 63 products to the eCR certification criterion or 13% of developers and 11% of products. Beginning in 2022, CMS 
                        <PRTPAGE P="1407"/>
                        required eligible hospitals and critical access hospitals in the Medicare Promoting Interoperability Program and eligible clinicians reporting on the Promoting Interoperability performance category in MIPS to report on use of eCR as part of the Public Health and Clinical Data Exchange Objective. The Electronic Case Reporting measure was optional in prior program years. Due to this new program requirement, we expect more Health IT Modules to certify the criterion in the coming year(s). As a proxy for possible future certification of eCR, we used the number of products that are currently certified to § 170.315(f)(1) (transmission to immunization registries) to estimate future certification of the eCR criterion. As of 2021, 31% of developers and 28% of products certified to the immunization criterion, but not the eCR certification criterion. We used these rates to estimate future certification of the eCR criterion. We estimate that 368 developers will certify 502 products impacted by this rulemaking. We estimate updates to the eCR certification criterion will impact 141 products certified by 114 developers for the first time (“New”) and 55 products already certified by 48 developers (“Current”) for an estimated total of 196 products certified by 162 developers.
                    </P>
                    <P>
                        • 
                        <E T="03">Wages are determined using BLS estimates.</E>
                         According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>272</SU>
                        <FTREF/>
                         We assume that other indirect costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage, including other indirect costs, is $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>272</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm.</E>
                        </P>
                    </FTNT>
                    <GPOTABLE COLS="5" OPTS="L2,nj,p7,7/8,i1" CDEF="s25,r50,6,6,r50">
                        <TTITLE>Table 10—Estimated Labor Hours To Meet eCR Certification Requirements—New Products</TTITLE>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Details</CHED>
                            <CHED H="1">Estimated labor hours</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                            <CHED H="1">Remarks</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1: Case Report Creation</ENT>
                            <ENT>(1) Enable a user to create a case report for electronic transmission according to (i) eICR profiles of HL7 FHIR eCR IG, or (ii) HL7 CDA eICR IG; (2) Support RCTC value set</ENT>
                            <ENT>1,000</ENT>
                            <ENT>1,500</ENT>
                            <ENT>
                                (1) Lower bound assumes health IT product has begun to implement at least one of the two IGs. 
                                <LI>(2) Upper bound assumes health IT product does not support either IG or has not begun to implement.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2: Case Report Response Receipt</ENT>
                            <ENT>Health IT Module must be able to consume and process a reportability response according to (1) RR profiles of HL7 FHIR eCR IG, or (2) HL7 CDA RR IG</ENT>
                            <ENT>1,000</ENT>
                            <ENT>1,500</ENT>
                            <ENT>
                                (1) Lower bound assumes health IT product has begun to implement at least one of the two IGs. 
                                <LI>(2) Upper bound assumes health IT product does not support either IG or has not begun to implement.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 3: Support for Reporting</ENT>
                            <ENT>Health IT Module must be able to report to a system capable of receiving case reports electronically</ENT>
                            <ENT>0</ENT>
                            <ENT>160</ENT>
                            <ENT>
                                (1) Lower bound assumes that health IT already has the technical pre-requisites for reporting but is not yet connected to platform or method to enable reporting. 
                                <LI>
                                    (2) Upper bound assumes health IT does not have technical pre-requisites for reporting (
                                    <E T="03">e.g.,</E>
                                     no support for electronic connection and no support for available exchange methods).
                                </LI>
                            </ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="5" OPTS="L2,nj,p7,7/8,i1" CDEF="s25,r50,6,6,r50">
                        <TTITLE>Table 11—Estimated Labor Hours to Meet eCR Certification Requirements—Currently Certified Products</TTITLE>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Details</CHED>
                            <CHED H="1">Estimated labor hours</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                            <CHED H="1">Remarks</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1: Case Report Creation</ENT>
                            <ENT>(1) Enable a user to create a case report for electronic transmission according to (i) eICR profiles of HL7 FHIR eCR IG, or (ii) HL7 CDA eICR IG; (2) Support RCTC value set</ENT>
                            <ENT>0</ENT>
                            <ENT>1,000</ENT>
                            <ENT>
                                (1) Lower bound assumes health IT product has already implemented at least one of the two IGs. 
                                <LI>(2) Upper bound assumes health IT product has begun to implement at least one of the two IGs.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2: Case Report Response Receipt</ENT>
                            <ENT>Health IT Module must be able to consume and process a reportability response according to (1) RR profiles of HL7 FHIR eCR IG, or (2) HL7 CDA RR IG</ENT>
                            <ENT>0</ENT>
                            <ENT>1,000</ENT>
                            <ENT>
                                (1) Lower bound assumes health IT product has already implemented at least one of the two IGs. 
                                <LI>(2) Upper bound assumes health IT product has begun to implement at least one of the two IGs.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 3: Support for Reporting</ENT>
                            <ENT>Health IT Module must be able to report to a system capable of receiving case reports electronically</ENT>
                            <ENT>0</ENT>
                            <ENT>160</ENT>
                            <ENT>
                                (1) Lower bound assumes health IT already supports at least one reporting option, such as to the AIMS platform, state-based registries or health information exchanges. 
                                <LI>(2) Upper bound assumes health IT does not have technical pre-requisites for reporting (e.g., no support for electronic connection and no support for available exchange methods).</LI>
                            </ENT>
                        </ROW>
                    </GPOTABLE>
                    <FP SOURCE="FP-2">
                        Total Costs, 
                        <E T="03">TC</E>
                         can be represented by the following equation:
                    </FP>
                    <GPH SPAN="3" DEEP="39">
                        <GID>ER09JA24.000</GID>
                    </GPH>
                    <EXTRACT>
                        <PRTPAGE P="1408"/>
                        <FP SOURCE="FP-2">
                            Number of currently certified products, 
                            <E T="03">p</E>
                            <E T="54">c</E>
                             = 55
                        </FP>
                        <FP SOURCE="FP-2">
                            Number of new certified products, 
                            <E T="03">p</E>
                            <E T="54">n</E>
                             = 141
                        </FP>
                        <FP SOURCE="FP-2">
                            Fully loaded wage, 
                            <E T="03">w</E>
                             = 127.82
                        </FP>
                        <FP SOURCE="FP-2">
                            Labor hours for IG implementation, 
                            <E T="03">h</E>
                            <E T="54">k</E>
                            , for each profile or IG, 
                            <E T="03">k</E>
                        </FP>
                        <FP SOURCE="FP-2">
                            Labor hours for reporting, 
                            <E T="03">h</E>
                            <E T="54">r</E>
                        </FP>
                    </EXTRACT>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,12,16,12">
                        <TTITLE>Table 12—Example Calculation for the Lower Bound Estimated Cost to New Products To Perform Task 1 in Table 10 To Meet eCR Certification Requirements</TTITLE>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated labor hours</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="1">Developer salary</CHED>
                            <CHED H="1">Projected products</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1</ENT>
                            <ENT>1,000 hours</ENT>
                            <ENT>$127.82 per hour</ENT>
                            <ENT>141 products</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22">
                                <E T="03">Example Calculation:</E>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03" O="xl">1,000 hours * $127.82 * 141 products = $18,022,620.</ENT>
                            <ENT O="xl"/>
                            <ENT O="xl"/>
                            <ENT O="xl"/>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,12,12">
                        <TTITLE>Table 13—Costs To Meet eCR Certification Requirements—New Products</TTITLE>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated labor hours</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1 (141 products)</ENT>
                            <ENT>$18,022,620</ENT>
                            <ENT>$27,033,930</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2 (141 products)</ENT>
                            <ENT>18,022,620</ENT>
                            <ENT>27,033,930</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Task 3 (141 products)</ENT>
                            <ENT>0</ENT>
                            <ENT>2,883,619</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Cost</ENT>
                            <ENT>36,045,240</ENT>
                            <ENT>56,951,479</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,12,12">
                        <TTITLE>Table 14—Costs To Meet eCR Certification Requirements—Currently Certified Products</TTITLE>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated cost</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1 (55 products)</ENT>
                            <ENT>$0</ENT>
                            <ENT>$7,030,100</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2 (55 products)</ENT>
                            <ENT>0</ENT>
                            <ENT>7,030,100</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Task 4 (55 products)</ENT>
                            <ENT>0</ENT>
                            <ENT>1,124,816</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Cost</ENT>
                            <ENT>0</ENT>
                            <ENT>15,185,016</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,12,12">
                        <TTITLE>Table 15—Costs To Meet eCR Certification Requirements—All Products</TTITLE>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated cost</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1 (196 products)</ENT>
                            <ENT>$18,022,620</ENT>
                            <ENT>$34,064,030</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2 (196 products)</ENT>
                            <ENT>18,022,620</ENT>
                            <ENT>34,064,030</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Task 3 (196 products)</ENT>
                            <ENT>0</ENT>
                            <ENT>4,008,435</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Cost</ENT>
                            <ENT>36,045,240</ENT>
                            <ENT>72,136,495</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>Based on the stated assumptions and costs outlined in Tables 13-15, the total estimated cost for certified health IT products to meet the finalized eCR certification criterion requirements will range from $36 million to $72.1 million. Assuming 162 health IT developers, there will be an average cost per developer ranging from $222,501 to $445,287, with an average cost per product ranging from $255,640 to $403,911 for new products and $0 to $276,091 for currently certified products.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        The primary benefit of adopting standards-based requirements for the eCR certification criterion is to improve consistency and promote interoperability over time. eCR is one of the pillars of ONC's and CMS' broader efforts to support effective healthcare data interoperability, which ensures that electronic health information is shared appropriately between healthcare organizations and public health agencies (PHAs) in the right format, through the right channel at the right time.
                        <SU>273</SU>
                        <FTREF/>
                         Adopting a standards-based approach to eCR facilitates the exchange of health information between healthcare and public health by requiring the use of a common format for the creation of case reports and processing of a reportability response.
                    </P>
                    <FTNT>
                        <P>
                            <SU>273</SU>
                             
                            <E T="03">https://www.cdc.gov/datainteroperability/index.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        Potential benefits of a centralized approach to eCR have been assessed in an Association of State and Territorial Health Officials (ASTHO)-sponsored economic analysis of the efficiencies gained at PHAs by using centralized eCR services through the Association of Public Health Laboratories (APHL) Informatics Messaging Services (AIMS) platform, rather than using localized eCR solutions or manual, paper-based methods.
                        <SU>274</SU>
                        <FTREF/>
                         A key component of this service is the inclusion of the CDC 
                        <PRTPAGE P="1409"/>
                        supported Council of State and Territorial Epidemiologists' (CSTE) developed decision support tool, Reportable Condition Knowledge Management System (RCKMS), which helps determine whether initial case reports are reportable in specific public health jurisdictions and eliminates confusion regarding where reports should be sent.
                        <E T="51">275 276</E>
                        <FTREF/>
                         According to the analysis, centralized eCR components could provide, “$2.5 million in increased efficiency per jurisdiction over 15 years” compared to manual reporting and “$310,000 of net benefits over 15 years” compared to localized eCR solutions.
                        <SU>277</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>274</SU>
                             
                            <E T="03">https://www.aphl.org/programs/informatics/Pages/aims_platform.aspx.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>275</SU>
                             CSTE Surveillance/Informatics: Reportable Conditions Knowledge Management Systems. CSTE website. 
                            <E T="03">http://www.cste.org/group/RCKMS.</E>
                        </P>
                        <P>
                            <SU>276</SU>
                             
                            <E T="03">https://ecr.aimsplatform.org/cms/resources/blocks/digital-bridge-ecr-evaluation-report-12-32019.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>277</SU>
                             Cooney MA, Iademarco MF, Huang M, MacKenzie WR, Davidson AJ. The public health community platform, electronic case reporting, and the digital bridge. Journal of Public Health Management and Practice. 2018 Mar 1;24(2):185-9.
                        </P>
                    </FTNT>
                    <P>Benefits of eCR to the healthcare sector and public health that will be promoted through standards adoption:</P>
                    <P>• Automatic, complete, accurate data reported in real-time (faster and more complete than manual entry) facilitates evidence-based decision-making for public health.</P>
                    <P>• Directly benefits public health response efforts by supporting situational awareness, case management, contract tracing, and efforts to coordinate isolation.</P>
                    <P>• Helps improve public health efficiency for evaluation and follow-up by providing PHAs with higher quality patient and clinical data in a timely manner.</P>
                    <P>• Reduces reporting burden for health care providers without disrupting clinical workflow, which can result in time and cost savings for the healthcare sector.</P>
                    <P>• Fulfills legal reporting requirements as well as CMS PI Program requirements for eCR, meaning benefits to public health would not come at an additional cost to health care providers who are already required to report.</P>
                    <P>• Streamlines reporting to multiple jurisdictions.</P>
                    <P>Benefits of certification criterion update:</P>
                    <P>• Adoption of standards for eCR will improve consistency and interoperability over time.</P>
                    <P>
                        • Consistency in the reporting of specific data elements will increase the efficiency of exchange (
                        <E T="03">e.g.,</E>
                         by facilitating automated reporting, enabling RCKMS and PHA processing of eICRs and bi-directional communication between providers and public health).
                    </P>
                    <P>• RCTC value set establishes a baseline for use in the Program and enables developers of certified health IT to support newer or updated versions of RCTC value sets as soon as new releases are available.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments regarding the impact analysis for updates to the electronic care reporting criterion.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The final impact analysis is consistent with the proposed rulemaking. Cost estimates were updated to reflect wages of software developers as of 2022.
                    </P>
                    <HD SOURCE="HD3">Decision Support Interventions and Predictive Models</HD>
                    <P>
                        In section III.C.5 of this preamble, we have finalized the proposed new certification criterion for “decisions support interventions” in § 170.315(b)(11) with modifications, including more clearly separating technical functionality and ongoing maintenance for transparency purposes. The intent of this certification criterion is to ensure the availability of sufficient information on decision support interventions based on predictive models, including machine learning and artificial intelligence, through a more comprehensive list of source attributes and through the conduct and documentation of risk management activities. That information is intended to enable the selection and use of fair (
                        <E T="03">i.e.,</E>
                         unbiased), appropriate, valid, and effective interventions. The certification criterion also would provide additional transparency into evidence-based decision support interventions by requiring that products allow decision support to be enabled based on specific data classes.
                    </P>
                    <HD SOURCE="HD3">Alternatives Considered</HD>
                    <P>We considered several alternative regulatory approaches, but believe this approach implies the lowest burden of available options while having a high likelihood of impacting decision-making. Because we seek to address a market failure related to inadequate and asymmetric information, we proposed an informational intervention. The approach is market-oriented and aimed at ensuring that model purchasers and users have sufficient information to select and use models responsibly. We believe that several alternative approaches, such as performance or design standards would imply substantially higher regulatory burden and are inappropriate given the ongoing research and development in this area and uncertainty inherent in predictive model development.</P>
                    <P>
                        Rather than mandatory reporting, we considered the potential for a voluntary database to which model developers might report information on the quality of their models. However, we are concerned that such a database would achieve relatively low participation because of disincentives for some developers to make the performance of their models' public. We believe that the current approach in which we have required reporting of a set of core source attributes that we strongly believe should be available for all models (
                        <E T="03">e.g.,</E>
                         intended use) and reporting of other attributes (
                        <E T="03">e.g.,</E>
                         external validation results) as required if available but otherwise providing the option to clearly label as missing, is a more effective balance between prescriptive requirements and voluntary participation. Given the national availability of many models, Federal regulation is beneficial to set a common set of expectations across the national market.
                    </P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs of the “Decision Support Intervention” certification criterion and associated maintenance of certification requirements. The cost estimates are based on the following assumptions:</P>
                    <P>
                        • 
                        <E T="03">Health IT developers will experience the assumed average costs of labor and data model use.</E>
                         Table 16 shows the estimated labor costs per product for a health IT developer to develop support for the predictive decision support certification criterion. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will, on average, incur the costs noted in Table 16.
                    </P>
                    <P>
                        • 
                        <E T="03">The number of health IT developers and products certified will closely align with certification of the 2015 Edition clinical decision support (CDS) criterion.</E>
                         We estimate that 301 products certified by 243 developers will be affected by our policy. These estimates are a subset of the total estimated health IT developers and certified products we estimated above. We estimate that, in total, 368 health IT developers will certify 502 health IT products impacted by this rulemaking. However, we estimate that not all these developers and products will certify the new Decision Support Intervention criterion. As of the end of 2021, 66% of developers and 60% of products certified to the 
                        <E T="03">CDS</E>
                         criterion. We assume that all products certified to the CDS criterion will certify the new 
                        <PRTPAGE P="1410"/>
                        Decision Support Intervention criterion. We, therefore, use certification of the CDS criterion as a proxy for the percent of developers and products that will certify the Decision Support Intervention criterion in the future. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products that will certify this criterion and be impacted by the costs of this new criterion.
                    </P>
                    <P>
                        • 
                        <E T="03">Wages are determined using BLS estimates.</E>
                         According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>278</SU>
                        <FTREF/>
                         We assume that other indirect costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage, including other indirect costs, is $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>278</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm.</E>
                        </P>
                    </FTNT>
                    <P>We believe developers will expend substantial initial effort to develop the technical capabilities to support the criterion and that their effort will be varied depending on the extent, scope, and scale necessary on their part to develop initial documentation related to source attributes and intervention risk management as required as part of their maintenance of certification to this certification criterion. In this final rule, we require that developers maintain and keep current information source attribute information for certain decision support interventions. We also have finalized requirements for an annual review of risk management information and documentation. We believe that both requirements imply sustained annual effort, which we have estimated in Table 16. However, we have constrained the scope of responsibility for developers of certified health IT under this final rule.</P>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,12,12,r100">
                        <TTITLE>Table 16—Estimated Labor Hours To Develop and Maintain Updated Decision Support Functionality</TTITLE>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Lower bound hours</CHED>
                            <CHED H="1">Upper bound hours</CHED>
                            <CHED H="1">Remarks</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1: Update decision support tools to enable interventions based on additional data classes and enable selection of Predictive DSI</ENT>
                            <ENT>1,000</ENT>
                            <ENT>1,600</ENT>
                            <ENT>
                                (1) Lower bound assumes health IT already has developed decision support modules that only need to be updated for new data classes.
                                <LI>(2) Upper bound assumes further data-structure related work is necessary to facilitate CDS based no additional classes.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2: Enable end-users to provide feedback on evidence-based DSI</ENT>
                            <ENT>200</ENT>
                            <ENT>1,000</ENT>
                            <ENT>
                                (1) Lower bound assumes that developers have already developed feedback capabilities and will need to make limited updates to the reporting of that information.
                                <LI>(2) Upper bound assumes that developer's current capability to support feedback on decision support needs to be significantly enhanced to support enabling end-users to provide effective feedback and to create reports from that feedback.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 3: Provide users the ability to record, change and access source attribute information</ENT>
                            <ENT>1,000</ENT>
                            <ENT>2,000</ENT>
                            <ENT>
                                (1) Lower bound assumes that existing tools used to create similar forms or documents can be adapted to this purpose.
                                <LI>(2) Upper bound assumes a higher burden due to more novel development.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 4: Provide complete and up-to-date source attribute information for Predictive DSI supplied by the developer</ENT>
                            <ENT>0 annually</ENT>
                            <ENT>800 annually</ENT>
                            <ENT>We expect a wide range of effort based on the extent to which developers make DSI available in the future, and whether they author Predictive DSI s available. For those that author Predictive DSI in the future and, we believe that evaluating and reporting source attributes for those Predictive DSI will imply substantial costs.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 5: Additional effort to provide information for source attributes related to Predictive DSI available as of December 31, 2024</ENT>
                            <ENT>0</ENT>
                            <ENT>1,600</ENT>
                            <ENT>We expect a wide range of effort based on the extent to which EHR developers currently author Predictive DSI s. For those that do author predictive decision supported interventions and do not currently evaluate the models on the attributes included, we believe doing so will imply substantial costs.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 6: Engage in risk management and annually update risk management information</ENT>
                            <ENT>0 annually</ENT>
                            <ENT>285 annually</ENT>
                            <ENT>We expect a wide range of effort based on the extent to which EHR developers currently author or execute Predictive DSI s. The total hours estimated to conduct real world testing per developer were 1,140 annually and that accounted for numerous criteria included as eligible for real world testing. We believe that conducting intervention risk management for (b)(11), including the provision of risk management documentation, would require a fraction of that time equivalent to one quarter of the time for real world testing.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 7: Additional initial engagement in risk management and updating risk management information available as of December 31, 2024</ENT>
                            <ENT>0</ENT>
                            <ENT>570</ENT>
                            <ENT>The total hours estimated to conduct real world testing per developer were 1,140 annually and that accounted for numerous criteria included as eligible for real world testing. We believe that conducting initial intervention risk management for, including the provision of risk management documentation, would require time equivalent to about one quarter of the time for real world testing.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>
                        Table 17 provides the overall costs projecting that 301 products will be certified to the criterion.
                        <PRTPAGE P="1411"/>
                    </P>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,15,20,20">
                        <TTITLE>Table 17—Total Cost to Developers To Develop and Maintain Updated Decision Support Functionality</TTITLE>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="1">Projected products</CHED>
                            <CHED H="1">
                                Estimated Total Cost (10 year)
                                <LI>
                                    (assuming software developer pay of $58.17 per hour software developers (
                                    <E T="03">bls.gov</E>
                                    ))
                                </LI>
                            </CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1</ENT>
                            <ENT>301</ENT>
                            <ENT>$38,473,820</ENT>
                            <ENT>$61,558,112</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2</ENT>
                            <ENT>301</ENT>
                            <ENT>7,694,764</ENT>
                            <ENT>38,473,820</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 3</ENT>
                            <ENT>301</ENT>
                            <ENT>38,473,820</ENT>
                            <ENT>76,947,640</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 4</ENT>
                            <ENT>301</ENT>
                            <ENT>0</ENT>
                            <ENT>307,790,560</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 5</ENT>
                            <ENT>301</ENT>
                            <ENT>0</ENT>
                            <ENT>61,558,112</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 6</ENT>
                            <ENT>301</ENT>
                            <ENT>0</ENT>
                            <ENT>109,650,387</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Task 7</ENT>
                            <ENT>301</ENT>
                            <ENT>0</ENT>
                            <ENT>21,930,077</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total</ENT>
                            <ENT/>
                            <ENT>84,642,404</ENT>
                            <ENT>677,908,708</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        Predictive DSIs are common, with some individual interventions being applied to tens or hundreds of millions of individuals despite, in some cases, crucial insufficiencies in the performance of those models.
                        <SU>279</SU>
                        <FTREF/>
                         However, there are a wide range of potential applications of Predictive DSI, and we believe that the healthcare delivery field is far from fully adopting these interventions in the circumstances where they would be beneficial. Because Predictive DSIs are currently, and potentially can be, applied to a wide range of contexts, comprehensively estimating quantitative benefits from improved interventions and underlying models is challenging, and for some types of benefits infeasible. However, we have generated some quantitative benefits related to the scope of potential cost savings and have identified additional benefits, characterized qualitatively, to the adopted certification criterion and its associated maintenance of certification requirements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>279</SU>
                             Ziad Obermeyer, et al., 
                            <E T="03">Dissecting racial bias in an algorithm used to manage the health of populations,</E>
                             366 Science (2019).
                        </P>
                        <P>
                            Andrew Wong, et al., 
                            <E T="03">External validation of a widely implemented proprietary sepsis prediction model in hospitalized patients,</E>
                             181 JAMA Internal Medicine (2021).
                        </P>
                        <P>
                            <E T="03">The Johns Hopkins ACG® System,</E>
                             available at 
                            <E T="03">https://www.johnshopkinssolutions.com/wp-content/uploads/2016/08/ACG-System-Brochure.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        We believe that the most directly quantifiable benefits of the adopted changes to predictive decision support relate to increased use of more accurate and effective Predictive DSIs.
                        <SU>280</SU>
                        <FTREF/>
                         We believe that increased transparency into the performance of models and risk management practices related to their development will result in (1) wider uptake of Predictive DSIs overall due to greater certainty about the intervention's performance, and (2) selection of fairer, more appropriate, more accurate, more effective and safer models through greater information on the available choices. However, we acknowledge that there is substantial uncertainty in the degree to which the policy will result in wider uptake and use of more effective interventions.
                    </P>
                    <FTNT>
                        <P>
                            <SU>280</SU>
                             
                            <E T="03">https://www.healthit.gov/buzz-blog/health-innovation/back-to-the-future-what-predictive-decision-support-can-learn-from-deloreans-and-the-big-short.</E>
                        </P>
                    </FTNT>
                    <P>
                        Given the sheer number of algorithms and applicable conditions and uses, we have selected two relevant scenarios—sepsis onset and ambulatory care sensitive admission—which have a fair amount of supporting research, to show the potential benefits of our policy. First, in patient populations in whom the risk of sepsis is moderate to high, risk-assessments based on patient factors and characteristics (
                        <E T="03">i.e.,</E>
                         data elements) are (or should be) made for implementing rapid risk-based patient care. The potential impact of using Predictive DSIs to more effectively conduct these risk-assessments can illustrate the benefits. Admissions for sepsis cost $24 billion per year 
                        <SU>281</SU>
                        <FTREF/>
                         and early detection of sepsis can lead to interventions that dramatically reduce those costs. However, advanced Predictive DSIs for the identification of sepsis are not widely used and instead older models, such as Sequential Organ Failure Assessment (SOFA), are dominant.
                        <SU>282</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>281</SU>
                             Epidemiology and Costs of Sepsis in the United States—An Analysis Based on Timing of Diagnosis and Severity Level*—PMC (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>282</SU>
                             J-L Vincent, et al., The SOFA (Sepsis-related Organ Failure Assessment) score to describe organ dysfunction/failure (Springer-Verlag 1996).
                        </P>
                    </FTNT>
                    <P>
                        Existing evidence indicates that more advanced predictive models can provide substantial performance improvements over simpler, widely used models.
                        <SU>283</SU>
                        <FTREF/>
                         The potential benefits of more advanced models are large. A prospectively evaluated sepsis Predictive DSI decreased in-hospital mortality related to sepsis by 39.5%, decreased length of stay by 32.3% and decreased readmission by 22.7% in one clinical trial.
                        <SU>284</SU>
                        <FTREF/>
                         However, there is also substantial uncertainty about whether models will offer that benefit when implemented on a broad scale. Performance of the same model evaluated in that clinical trial was substantially lower in a separate evaluation,
                        <SU>285</SU>
                        <FTREF/>
                         and that difference may be attributable to difference in performance in varied deployments and locations.
                    </P>
                    <FTNT>
                        <P>
                            <SU>283</SU>
                             As one example of a study demonstrating clear accuracy improvements over widely used, simpler models see Ryan J Delahanty, et al., 
                            <E T="03">Development and evaluation of a machine learning model for the early identification of patients at risk for sepsis,</E>
                             73 Annals of Emergency Medicine (2019).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>284</SU>
                             Burdick, Hoyt, et al. “Effect of a sepsis prediction algorithm on patient mortality, length of stay and readmission: a prospective multicentre clinical outcomes evaluation of real-world patient data from US hospitals.” BMJ health &amp; care informatics 27.1 (2020).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>285</SU>
                             Topiwala, Raj, et al. “Retrospective observational study of the clinical performance characteristics of a machine learning approach to early sepsis identification.” 
                            <E T="03">Critical Care Explorations</E>
                             1.9 (2019).
                        </P>
                    </FTNT>
                    <P>
                        Transparency has the potential to shed light on the variation in performance across models and to drive uptake of higher performing models. A systematic review of predictive models designed to detect early onset of sepsis found that published evaluations demonstrated sensitivities ranging from 64% to 98%.
                        <SU>286</SU>
                        <FTREF/>
                         One sepsis model that was recently widely adopted was found in subsequent validation to have relatively poor performance with a sensitivity of 33%. This again highlights 
                        <PRTPAGE P="1412"/>
                        the potential value of greater information to evaluate these models.
                        <SU>287</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>286</SU>
                             Hassan, Nehal, et al. “Preventing sepsis; how can artificial intelligence inform the clinical decision-making process? A systematic review.” 
                            <E T="03">International Journal of Medical Informatics</E>
                             150 (2021): 104457. 
                        </P>
                        <P>
                            Makam, Anil N., Oanh K. Nguyen, and Andrew D. Auerbach. “Diagnostic accuracy and effectiveness of automated electronic sepsis alert systems: a systematic review.” 
                            <E T="03">Journal of hospital medicine</E>
                             10.6 (2015): 396-402.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>287</SU>
                             Wong, Andrew, et al. “External validation of a widely implemented proprietary sepsis prediction model in hospitalized patients.” 
                            <E T="03">JAMA Internal Medicine</E>
                             181.8 (2021): 1065-1070.
                        </P>
                    </FTNT>
                    <P>Given the heterogeneity in the literature, it is challenging to estimate the extent to which the availability of information that will be facilitated by our policy will impact the average quality of predictive models used or how that average quality will evolve over time. Because models often perform less effectively in real-world implementation than in test environments, we believe the likely impact will be smaller than that implied by the literature but believe an impact on the average sensitivity of models used of 5 percentage points is reasonable. We note that in the cited systematic review, the median sensitivity of included models was 81% so that our assumption is that with the rule in place median sensitivity of available models will increase by 5 percentage points to 86%. Based on cost savings indicated in the available literature, we estimate that early detection of onset will result in cost savings of 50% for the incrementally more commonly detected patient event.</P>
                    <P>
                        Beyond increases in the accuracy and effectiveness of models used, it is also challenging to estimate the extent to which the adopted certification criterion will result in increased use of more accurate decision support interventions. Findings on other transparency related public policies, such as nutrition labels, indicate that use of labels can have substantial impacts on consumers choices.
                        <SU>288</SU>
                        <FTREF/>
                         While these findings indicate a likely increase in use of interventions from transparency related policies, we believe it is difficult to transfer these findings to the specific case of Predictive DSIs. We are assuming that the policy will relate to application of improved models (with an average increased sensitivity of 5%) by 2% a year beginning in the year that requirements commenced.
                    </P>
                    <FTNT>
                        <P>
                            <SU>288</SU>
                             For examples, see Joanne F Guthrie, et al., 
                            <E T="03">Who uses nutrition labeling, and what effects does label use have on diet quality?</E>
                             27 Journal of Nutrition education (1995); Marian L Neuhouser, et al., 
                            <E T="03">Use of food nutrition labels is associated with lower fat intake,</E>
                             99 Journal of the American dietetic Association (1999).
                        </P>
                    </FTNT>
                    <P>
                        Another example we wish to highlight along with sepsis is the use of models to identify patients at risk for ambulatory care sensitive conditions (ACSCs). Such conditions result in costs of $33.7 billion (bn) per year.
                        <SU>289</SU>
                        <FTREF/>
                         As in the sepsis example, there are several existing predictive models, and they exhibit a wide range accuracy.
                        <SU>290</SU>
                        <FTREF/>
                         We therefore believe it is reasonable to apply the estimates used in the prior example related to sepsis onset to estimate potential benefits related to ambulatory care-sensitive admissions. Given substantial differences in the sensitivity of models intended to identify patients at risk of ambulatory care-sensitive admissions, we believe this assumption is reasonable.
                        <SU>291</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>289</SU>
                             
                            <E T="03">https://www.hcup-us.ahrq.gov/reports/statbriefs/sb259-Potentially-Preventable-Hospitalizations-2017.jsp.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>290</SU>
                             Emma Wallace, et al., 
                            <E T="03">Risk prediction models to predict emergency hospital admission in community-dwelling adults: a systematic review,</E>
                             52 Medical Care (2014).
                        </P>
                        <P>
                            Seung Eun Yi, et al., 
                            <E T="03">Predicting hospitalisations related to ambulatory care sensitive conditions with machine learning for population health planning: derivation and validation cohort study,</E>
                             12 BMJ Open (2022).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>291</SU>
                             Garcia-Arce, Andres, Florentino Rico, and José L. Zayas-Castro. “Comparison of machine learning algorithms for the prediction of preventable hospital readmissions.” 
                            <E T="03">The Journal for Healthcare Quality (JHQ)</E>
                             40.3 (2018): 129-138.
                        </P>
                    </FTNT>
                    <P>We estimate all benefits on a 10-year time horizon. Because developers of certified health IT with Health IT Modules certified to the existing certification criterion in § 170.315(a)(9) are not required to certify to the adopted criterion in § 170.315(b)(11) until 2024, we note that benefits would not commence until the third year. We believe that period of time allows sufficient time for the full impact of the policy to take effect, including developer certification to the criterion, publication of risk management information, and hospital resorting to improved predictive models. We expect that the use of predictive models in healthcare will continue to evolve well beyond that time horizon; however, given the dynamic and uncertain nature of this area, we do not believe it would be appropriate to provide estimates beyond that period.</P>
                    <P>We examined the sensitivity of our estimated benefits based on uncertainty in the underlying rates. We varied two rates: the average increase in the sensitivity of models used and the increased rate at which more accurate models were used. Specifically, we recalculated benefits with an assumed sensitivity increase of 2.5%, 5% or 10% (with 5% representing our primary estimate) and an assumed increase in application of models of 1%, 2% and 3% (with 2% representing our primary estimate). In these analyses, we estimated that the 10-year undiscounted incremental impacts ranged from $259,650,000 to $3,115,800,000. We also estimated the annualized benefits of the incremental impacts using alternative modeling assumptions and present them in Table 19.</P>
                    <GPOTABLE COLS="9" OPTS="L2,p7,7/8,i1" CDEF="s25,9,13,10,11,16,12,13,xs24">
                        <TTITLE>Table 18—Select Benefits to Patients and Payers From Updated Decision Support Functionality</TTITLE>
                        <BOXHD>
                            <CHED H="1">Year impacts are incurred</CHED>
                            <CHED H="1">
                                Cost of
                                <LI>sepsis</LI>
                                <LI>admission</LI>
                                <LI>(bn)</LI>
                            </CHED>
                            <CHED H="1">
                                Proportion
                                <LI>of admissions for which more sensitive model used</LI>
                            </CHED>
                            <CHED H="1">
                                Increased
                                <LI>sensitivity</LI>
                                <LI>of models</LI>
                                <LI>used</LI>
                            </CHED>
                            <CHED H="1">Assumed costs saved for impacted admissions</CHED>
                            <CHED H="1">
                                Incremental
                                <LI>impacts</LI>
                                <LI>(undiscounted) *</LI>
                            </CHED>
                            <CHED H="1">
                                Incremental
                                <LI>impacts</LI>
                                <LI>(7% discount)</LI>
                            </CHED>
                            <CHED H="1">
                                Incremental
                                <LI>impacts</LI>
                                <LI>(3% discount)</LI>
                            </CHED>
                            <CHED H="1"> </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">1</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>$0.00</ENT>
                            <ENT>$0.00</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>0.00</ENT>
                            <ENT>0.00</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">3</ENT>
                            <ENT>$24</ENT>
                            <ENT>0.02</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>$12,000,000</ENT>
                            <ENT>9,795,575</ENT>
                            <ENT>10,981,670</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">4</ENT>
                            <ENT>24</ENT>
                            <ENT>0.04</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>24,000,000</ENT>
                            <ENT>18,309,485</ENT>
                            <ENT>21,323,689</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5</ENT>
                            <ENT>24</ENT>
                            <ENT>0.06</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>36,000,000</ENT>
                            <ENT>25,667,502</ENT>
                            <ENT>31,053,916</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">6</ENT>
                            <ENT>24</ENT>
                            <ENT>0.08</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>48,000,000</ENT>
                            <ENT>31,984,427</ENT>
                            <ENT>40,199,244</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">7</ENT>
                            <ENT>24</ENT>
                            <ENT>0.1</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>60,000,000</ENT>
                            <ENT>37,364,985</ENT>
                            <ENT>48,785,491</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">8</ENT>
                            <ENT>24</ENT>
                            <ENT>0.12</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>72,000,000</ENT>
                            <ENT>41,904,656</ENT>
                            <ENT>56,837,465</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">9</ENT>
                            <ENT>24</ENT>
                            <ENT>0.14</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>84,000,000</ENT>
                            <ENT>45,690,434</ENT>
                            <ENT>64,379,006</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">10</ENT>
                            <ENT>24</ENT>
                            <ENT>0.16</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>96,000,000</ENT>
                            <ENT>48,801,532</ENT>
                            <ENT>71,433,016</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>432,000,000.00</ENT>
                            <ENT>259,518,595</ENT>
                            <ENT>344,993,527</ENT>
                            <ENT>PV</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>36,949,610</ENT>
                            <ENT>40,443,766</ENT>
                            <ENT>Ann</ENT>
                        </ROW>
                    </GPOTABLE>
                    <PRTPAGE P="1413"/>
                    <GPOTABLE COLS="9" OPTS="L2(0,,),ns,tp0,p7,7/8,i1" CDEF="s25,9,13,10,11,16,12,13,xs24">
                        <TTITLE> </TTITLE>
                        <BOXHD>
                            <CHED H="1">Year impacts are incurred</CHED>
                            <CHED H="1">
                                Cost of
                                <LI>ambulatory</LI>
                                <LI>sensitive</LI>
                                <LI>admission</LI>
                                <LI>(bn)</LI>
                            </CHED>
                            <CHED H="1">
                                Proportion
                                <LI>of admissions for which more sensitive model used</LI>
                            </CHED>
                            <CHED H="1">
                                Increased
                                <LI>sensitivity</LI>
                                <LI>of models</LI>
                                <LI>used</LI>
                            </CHED>
                            <CHED H="1">Assumed costs saved for impacted admissions</CHED>
                            <CHED H="1">
                                Incremental
                                <LI>impacts</LI>
                                <LI>(undiscounted) *</LI>
                            </CHED>
                            <CHED H="1">
                                Incremental
                                <LI>impacts</LI>
                                <LI>(7% discount)</LI>
                            </CHED>
                            <CHED H="1">
                                Incremental
                                <LI>impacts</LI>
                                <LI>(3% discount)</LI>
                            </CHED>
                            <CHED H="1"> </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">1</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">2</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">3</ENT>
                            <ENT>$33.7</ENT>
                            <ENT>0.02</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>$16,850,000</ENT>
                            <ENT>$13,754,619</ENT>
                            <ENT>$15,420,136</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">4</ENT>
                            <ENT>33.7</ENT>
                            <ENT>0.04</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>33,700,000</ENT>
                            <ENT>25,709,569</ENT>
                            <ENT>29,942,014</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5</ENT>
                            <ENT>33.7</ENT>
                            <ENT>0.06</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>50,550,000</ENT>
                            <ENT>36,041,451</ENT>
                            <ENT>43,604,874</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">6</ENT>
                            <ENT>33.7</ENT>
                            <ENT>0.08</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>67,400,000</ENT>
                            <ENT>44,911,466</ENT>
                            <ENT>56,446,439</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">7</ENT>
                            <ENT>33.7</ENT>
                            <ENT>0.1</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>84,250,000</ENT>
                            <ENT>52,466,666</ENT>
                            <ENT>68,502,960</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">8</ENT>
                            <ENT>33.7</ENT>
                            <ENT>0.12</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>101,100,000</ENT>
                            <ENT>58,841,120</ENT>
                            <ENT>79,809,274</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">9</ENT>
                            <ENT>33.7</ENT>
                            <ENT>0.14</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>117,950,000</ENT>
                            <ENT>64,156,985</ENT>
                            <ENT>90,398,854</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">10</ENT>
                            <ENT>33.7</ENT>
                            <ENT>0.16</ENT>
                            <ENT>0.05</ENT>
                            <ENT>0.5</ENT>
                            <ENT>134,800,000</ENT>
                            <ENT>68,525,485</ENT>
                            <ENT>100,303,860</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>606,600,000</ENT>
                            <ENT>364,407,361</ENT>
                            <ENT>484,428,410</ENT>
                            <ENT>PV</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>51,883,410</ENT>
                            <ENT>56,789,788</ENT>
                            <ENT>Ann</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,12,12,12">
                        <TTITLE>Table 19—Select Benefits From Updated Decision Support Functionality Under Alternative Assumptions, $ Millions, Annualized, 3% Discount Rate</TTITLE>
                        <BOXHD>
                            <CHED H="1">
                                Impact on annual model application
                                <LI>(%)</LI>
                            </CHED>
                            <CHED H="1">Impact on model sensitivity</CHED>
                            <CHED H="2">2.50%</CHED>
                            <CHED H="2">5%</CHED>
                            <CHED H="2">10%</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">1</ENT>
                            <ENT>$24.3</ENT>
                            <ENT>$48.6</ENT>
                            <ENT>$97.2</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2</ENT>
                            <ENT>48.6</ENT>
                            <ENT>97.2</ENT>
                            <ENT>194.5</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">3</ENT>
                            <ENT>72.9</ENT>
                            <ENT>145.9</ENT>
                            <ENT>291.7</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>We have highlighted one condition and one event that will benefit from the more widespread use of more accurate predictive models under this final rule. There are numerous other conditions and events in which increased sensitivity could offer substantial cost savings. However, given uncertainty in the estimates around the included estimates, and important differences across various conditions and the extent to which Predictive DSIs might impact care, we are not confident that the assumptions generated here are transferable to other contexts.</P>
                    <P>
                        In addition to benefits associated with more sensitive models, we believe that there are numerous other potential benefits related to the more widespread use of more accurate predictive decision support. However, many of the benefits associated with greater accuracy, specific models, such as reduced inappropriate treatment or reduced burdens on providers, are difficult to quantify and have to date been targeted by fewer predictive models. For salient examples, we note that false-positives for screening for with $4 billion per year and that more specific interventions could reduce the rates of false-positives.
                        <SU>292</SU>
                        <FTREF/>
                         We further note that provider burnout and fatigue are important and costly issues, we believe these benefits may be large.
                        <SU>293</SU>
                        <FTREF/>
                         However, since we are aware of fewer estimates around the potential impact of Predictive DSIs to address these issues, we have not attempted to quantify the potential benefits associated with their use.
                    </P>
                    <FTNT>
                        <P>
                            <SU>292</SU>
                             Ong, Mei-Sing, and Kenneth D. Mandl. “National expenditure for false-positive mammograms and breast cancer overdiagnoses estimated at $4 billion a year.” 
                            <E T="03">Health affairs</E>
                             34.4 (2015): 576-583.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>293</SU>
                             Gregory, Megan E., Elise Russo, and Hardeep Singh. “Electronic health record alert-related workload as a predictor of burnout in primary care providers.” 
                            <E T="03">Applied clinical informatics</E>
                             8.03 (2017): 686-697.
                        </P>
                    </FTNT>
                    <P>
                        Beyond the benefits associated with greater use of accurate models, we believe there will be several important benefits associated with the adopted transparency requirements. We believe that increased transparency into the intended use of models will increase the appropriate use of models. There is concern that models will be applied to populations, contexts, and decisions for which they are not well-suited to provide accurate information.
                        <SU>294</SU>
                        <FTREF/>
                         A transparent display of the intended use and what is out of scope could reduce the occurrence of treatment decisions resulting in harm. However, we are not aware of efforts to quantify harm from misapplied models today.
                    </P>
                    <FTNT>
                        <P>
                            <SU>294</SU>
                             Richard Ribón Fletcher, et al., 
                            <E T="03">Addressing fairness, bias, and appropriate use of artificial intelligence and machine learning in global health,</E>
                             3 Frontiers in Artificial Intelligence (2021).
                        </P>
                    </FTNT>
                    <P>We believe increased transparency into models and practices will result in the selection and use of fairer models. Biased models, for instance, exhibit higher sensitivity or specificity for some groups than others and are likely to deprioritize treatment for certain groups. They are also likely to recommend inappropriate treatment for certain groups resulting in limited benefit and potential harm to those certain groups relative to those for whom models the perform well. Reliance on biased models, particularly those used in the context of preventive care or early identification of a disease, could result in greater costs for groups in which the model performs poorly compared to developing a fairer model or not using the model altogether. Greater transparency into the fairness of models will enable users to select fairer models and reward producers of fairer models. This will lead to the selection of models that further, opposed to hinder, the equitable delivery of healthcare to groups that have been marginalized. We requested comment on the feasibility of quantifying benefits associated with increased model fairness, which may be identifiable through the increased benefits to groups that have been marginalized.</P>
                    <P>
                        We believe that increased transparency will lead to an effective market for predictive models that adequately incentivizes and rewards high-quality models. Currently, model developers have an information advantage relative to consumers, and consumers of models act under considerable uncertainty regarding the quality of the product they are acquiring. This market dynamic can lead to harmful choices by consumers and inadequate reward for high quality developers, potentially leading to a 
                        <PRTPAGE P="1414"/>
                        feedback loop through adverse selection that encourages market exit by high quality, high-cost model developers. However, adequately characterizing the benefits of a higher information market to the overall quality of models developed and sold is not feasible.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments on this analysis.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The final impact analysis was updated to include the expected annual costs for applicable developers of certified health IT to meet annual documentation requirements. Cost estimates were also updated to reflect wages of software developers as of 2022.
                    </P>
                    <HD SOURCE="HD3">Synchronized Clocks Standard</HD>
                    <P>In section III.C.6 of this preamble, we discuss the proposed removal of the current named specification for clock synchronization, which is Network Time Protocol (NTP v4 of RFC 5905), in 45 CFR 170.210(g). However, we proposed to maintain an expectation that Health IT Modules certified to applicable certification criteria continue to utilize any network time protocol (NTP) standard that can ensure a system clock has been synchronized and meets the time accuracy requirements as defined in the applicable certification criteria in § 170.315(d)(2), (3), (10), and (e)(1).</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>
                        This policy is not intended to place additional burden on health IT developers as it does not require new development or implementation. Rather, a health IT developer's costs will be 
                        <E T="03">de minimis</E>
                         because we are providing flexibility to allow health IT developers to use any NTP standard that exists. We welcomed comments on these expectations.
                    </P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>We believe leveraging existing NTP standards and not requiring a specific standard allows for more flexibility. We have heard from health IT developers that the current required functionality is in place but not fully used. This policy allows for additional flexibility to meet the time accuracy requirements as defined in applicable certification criteria. For example, under this policy, Microsoft-based certified health IT using Operating System to synchronize network time, may use Microsoft's version of Network Time Protocol (MS NTP) as an alternative to Network Time Protocol Version 4 (NTP v4) of RFC 5905 as specified in § 170.210(g), and must meet the time accuracy requirement as defined in the certification criteria. We welcomed comments regarding potential approaches for quantifying these benefits.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments on this section of the analysis.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the impact analysis as proposed for this section.
                    </P>
                    <HD SOURCE="HD3">Standardized API for Patient and Population Services</HD>
                    <P>As discussed in section III.C.7 of this preamble, we have finalized as proposed, to update the certification criterion, “standardized API for patient and population services,” to align with updated standards and new requirements. We have finalized as proposed, to adopt the SMART App Launch Implementation Guide Release 2.0.0 in § 170.215(c)(2), which would replace SMART Application Launch Framework Implementation Guide Release 1.0.0 in § 170.215(a)(3) (finalized in this rule in § 170.215(c)(1)).</P>
                    <P>We also have finalized as proposed, to revise the requirement in § 170.315(g)(10)(vi) to specify that Health IT Modules presented for certification that allow short-lived access tokens to expire, in lieu of immediate access token revocation, must be able to revoke an authorized application's access at a patient's direction within one hour of the request.</P>
                    <P>Additionally, we have finalized to amend the API Condition and Maintenance of Certification requirements by adding the requirement that Certified API Developers with patient-facing APIs must publish their service base URLs for all customers, regardless of whether the certified Health IT Modules are centrally managed by the Certified API Developer or locally deployed by an API Information Source. We have finalized that these service base URLs must conform to a specific data format.</P>
                    <P>Finally, we have also adopted the FHIR US Core Implementation Guide STU version 6.1.0 in § 170.215(b)(1)(ii). Health IT systems that adopt this version of the US Core IG can provide the latest consensus-based capabilities for providing access to USCDI v3 data classes and elements using a FHIR API.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>We have estimated the cost to health IT developers to make these updates. These estimates are detailed in Table 20 below and are based on the following assumptions:</P>
                    <P>
                        <E T="03">1. Health IT developers will experience the assumed average costs of labor and data model use.</E>
                         Table 20 shows the estimated labor costs per product for a health IT developer to implement these updates to the criterion. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will on average, incur the costs noted in Table 20.
                    </P>
                    <P>
                        <E T="03">2.We estimate that 276 products certified by 228 developers will be affected by our policies.</E>
                         These estimates are a subset of the total estimated health IT developers and certified products we estimated above. We estimate that in total, 368 health IT developers will certify 502 health IT products impacted by this rulemaking. However, not all these developers and products will certify the 
                        <E T="03">Standardized API</E>
                         criterion and need to meet these adopted requirements. As of the end of 2021, 62% of developers and 55% of products certified the “application access—data category request” criterion. By December 31, 2022, all products that certify this criterion must certify the new standardized API criterion. We, therefore, use current certification of the data category request criterion as a proxy for the percent of developers and products certified to the standardized API criterion in the future. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by these updates to the standardized API criterion.
                    </P>
                    <P>
                        <E T="03">3. Wages are determined using BLS estimates.</E>
                         According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91. As noted previously, we have assumed that other indirect costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including other indirect costs is $128.
                        <PRTPAGE P="1415"/>
                    </P>
                    <GPOTABLE COLS="5" OPTS="L2,nj,i1" CDEF="s50,r60,6,6,r60">
                        <TTITLE>Table 20—Estimated Labor Hours To Update Standardized API for Patient and Population Services</TTITLE>
                        <BOXHD>
                            <CHED H="1">Task</CHED>
                            <CHED H="1">Details</CHED>
                            <CHED H="1">
                                Lower
                                <LI>bound</LI>
                                <LI>hours</LI>
                            </CHED>
                            <CHED H="1">
                                Upper
                                <LI>bound</LI>
                                <LI>hours</LI>
                            </CHED>
                            <CHED H="1">Remarks</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1: Implementation to the FHIR US Core IG 6.1.0 (per product)</ENT>
                            <ENT>Implement FHIR US Core IG v6.1.0 to update API to conform to US Core v6.1.0, which adopts the USCDIv3 data classes and elements</ENT>
                            <ENT>500</ENT>
                            <ENT>1,000</ENT>
                            <ENT>(1) Lower bound assumes health IT product voluntarily updated to USCDIv3 through SVAP. (2) Upper bound assumes health IT product only supports USCDIv1 and needs to update API to support resources aligned with data elements in USCDIv3.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2: Service-base URL Publication (per developer)</ENT>
                            <ENT>(1) Publish service-base URL in FHIR Endpoint resource format (2) Publish API Information Source organization information in Organization resource format (3) Make both available as FHIR bundle</ENT>
                            <ENT>250</ENT>
                            <ENT>1,000</ENT>
                            <ENT>(1) Lower bound assumes API Technology Supplier met the ONC Cures Act Final Rule service-base URL maintenance of certification requirement and published endpoint and organization data in these standard formats. (2) Upper bound assumes API Technology Supplier met the Cures Final Rule service-base URL maintenance of certification requirement but did not publish in the standard format.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 3: Develop support of 60-minute access revocation (per product)</ENT>
                            <ENT>Develop support for patients to revoke access to authorized app and for revocation to be fulfilled by server within 60 minutes of request</ENT>
                            <ENT>50</ENT>
                            <ENT>100</ENT>
                            <ENT>(1) Lower bound assumes developer needs to modify current revocation process and not rebuild is necessary. (2) Upper bound assumes revocation process exists, as required by ONC Cures Act Final Rule, but needs to be reprogrammed to accommodate new revocation step.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 4: Update security via SMART App Launch Framework to IG 2.0 (per product)</ENT>
                            <ENT>Update API from SMART App Launch Framework IG 1.0 to IG 2.0</ENT>
                            <ENT>500</ENT>
                            <ENT>1,000</ENT>
                            <ENT>(1) Lower bound assumes update to SMART App Launch Framework IG 2.0 underway. (2) Upper bound assumes update to Framework IG 2.0 not underway.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,12C,12C,12C">
                        <TTITLE>Table 21—Example Calculation for the Lower Bound Estimated Cost to Products To Perform Task 1 in Table 20 To Update API </TTITLE>
                        <TDESC>[2022 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated labor hours</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="1">
                                Developer
                                <LI>salary</LI>
                                <LI>(per hour)</LI>
                            </CHED>
                            <CHED H="1">Projected products</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1</ENT>
                            <ENT>500</ENT>
                            <ENT>$128</ENT>
                            <ENT>276</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Example calculation: 500 * $128 * 276 products = $17,664,000</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s50,12,12">
                        <TTITLE>Table 22—Total Cost To Update Standardized API for Patient and Population Services</TTITLE>
                        <TDESC>[2022 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated cost</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1 (276 products)</ENT>
                            <ENT>$17,664,000</ENT>
                            <ENT>$35,328,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2 (228 developers)</ENT>
                            <ENT>7,296,000</ENT>
                            <ENT>29,184,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 3 (276 products)</ENT>
                            <ENT>1,766,400</ENT>
                            <ENT>3,532,800</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Task 4 (276 products)</ENT>
                            <ENT>17,664,000</ENT>
                            <ENT>35,328,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total (276 products and 228 developers)</ENT>
                            <ENT>44,390,400</ENT>
                            <ENT>103,372,800</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>The cost to a health IT developer to update the standardized API criterion for their certified Health IT Modules will range from $166,000 to $397,000 per product, on average. Therefore, assuming 276 products overall and a labor rate of $128 per hour, we estimate that the total cost to all health IT developers will on average, range from $44 million to $103 million. This will be a one-time cost to developers per product that is certified to the specified certification criterion and will not be perpetual.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        We believe these policies will benefit health care providers, patients, and the industry. The adoption of the FHIR US Core IG v6.1.0 will, with the additional data elements in USCDI v3, expand the baseline set of data available and 
                        <PRTPAGE P="1416"/>
                        provide more comprehensive health data for both providers and patients. Updates to the SMART App Launch Framework IG 2.0 will align the certified API functionality with current adopted standards-based methods to connect patients' health information to the app of their choice. Furthermore, updated requirements to the service-base URL publication API maintenance of certification requirement will provide a standard format for all published FHIR endpoints to be securely discovered and consumed by authorized applications. The standard publication format will reduce the burden on patients, app developers, and other third parties to find and connect to the appropriate FHIR endpoint to initiate data access. This will directly benefit the speed and efficiency of making these connections and reduce the level of effort on third parties to access and use these standards-based APIs.
                    </P>
                    <P>We expect the resulting improvements to interoperable exchange of health information to significantly benefit providers and patients and improve the quality of healthcare provided. In the ONC Cures Act Final Rule (85 FR 25925), we estimated the total annual benefit of APIs on average, to range from $0.34 billion to $1.43 billion. These updates to the criterion ensure the benefits of APIs are maintained and the annual benefit due to improved health outcomes and patients having access to their online medical record is realized.</P>
                    <P>
                        As described previously, there are additional potential future benefits to the expanded availability of an interoperable API for patient and population services that are not quantifiable at this time. For some use cases, there is a clear indication of future technical direction, but currently there is insufficient implementation to clearly quantify the scope. For example, CMS has identified an intent to leverage APIs for population services in order to modernize quality measurement and quality reporting under value-based payment programs.
                        <SU>295</SU>
                        <FTREF/>
                         In 2016, a report found that quality measurement reporting bears an estimate $15.4 billion cost on clinicians for chart abstraction, data validation, and measure reporting.
                        <SU>296</SU>
                        <FTREF/>
                         The potential future use of FHIR-based APIs for quality measurement could provide greater ability to implement real time data for quality purposes and drastically reduce the costs of manual quality reporting workflows. We sought comment on potential means to estimate these benefits and future cost savings.
                    </P>
                    <FTNT>
                        <P>
                            <SU>295</SU>
                             CMS Digital Quality Roadmap, March 2022: 
                            <E T="03">https://ecqi.healthit.gov/sites/default/files/CMSdQMStrategicRoadmap_032822.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>296</SU>
                             Health Aff (Millwood), March 2016. 
                            <E T="03">US Physician Practices Spend More Than $15.4 Billion Annually To Report Quality Measures. https://pubmed.ncbi.nlm.nih.gov/26953292/.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments related to this impact analysis of updates to the standardized API criterion.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The final impact analysis is consistent with the proposed rulemaking. Cost estimates were updated to reflect wages of software developers as of 2022.
                    </P>
                    <HD SOURCE="HD3">Patient Demographics and Observations Certification Criterion</HD>
                    <P>
                        As discussed in section III.C.8 of this preamble, we have finalized as proposed to rename the “demographics” certification criterion (§ 170.315(a)(5)) to “
                        <E T="03">patient demographics and observations.”</E>
                         We have finalized as proposed to add the data elements “Sex Parameter for Clinical Use” in § 170.315(a)(5)(i)(F), “Name to Use” in § 170.315(a)(5)(i)(G), and “Pronouns” in § 170.315(a)(5)(i)(H) to the “Patient demographics and observations” certification criterion (§ 170.315(a)(5)). Additionally, we have finalized as proposed to replace the terminology standards specified for “Sex” in § 170.315(a)(5)(i)(C), “Sexual Orientation” in § 170.315(a)(5)(i)(D), and “Gender Identity” in § 170.315(a)(5)(i)(E). As such, ONC has finalized as proposed to remove the fixed list of terms for “Sex” in § 170.315(a)(5)(i)(C), “Sexual Orientation” in § 170.315(a)(5)(i)(D), and “Gender Identity” in § 170.315(a)(5)(i)(E) which are represented by SNOMED CT and HL7® Value Sets for AdministrativeGender and NullFlavor in § 170.207(o)(1) and (2)), and replace it with the SNOMED CT code sets specified in § 170.207(n)(2) and (o)(3).
                    </P>
                    <P>The proposed modifications to the “patient demographics and observations” criterion will provide greater clarity and standardization to how a patient's sexual orientation and gender identity are recorded electronically in the electronic health record. The USCDI v3 standard includes new data elements for Sexual Orientation and Gender Identity. These data elements are required to be included as part of a patient's electronic health information and included in any record shared with the patient, the patient's caregiver, or health care provider.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>The adopted modifications to the “patient demographics and observations” criterion include 6 tasks: (1) Modify Sex, (2) Modify Sexual Orientation, (3) Modify Gender Identity, (4) Add Sex Parameter for Clinical Use, (5) Add Pronouns, and (6) Add Name to Use. These tasks have their own level of effort, and these estimates are detailed in Table 23 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 23 shows the estimated labor costs per product to modify the “patient demographics and observations” criterion. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will incur the costs noted in Table 23.</P>
                    <P>2. We estimate that 321 products certified by 261 developers will be affected by our policy. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.</P>
                    <P>The estimate of 321 products certified by 261 developers is derived as follows. We estimate that, in total, 368 health IT developers would certify 502 health IT products impacted by this rulemaking. However, not all these developers and products certify the “patient demographics and observations” criterion and need to meet the adopted requirements. As of the end of 2021, 71% of developers and 64% of products certified to the criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the modifications to the criterion.</P>
                    <P>
                        3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91. As noted previously, we have assumed that other indirect costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including other indirect costs is $128.
                        <PRTPAGE P="1417"/>
                    </P>
                    <GPOTABLE COLS="4" OPTS="L2,nj,i1" CDEF="s50,r50,11,11">
                        <TTITLE>
                            Table 23—Estimated Labor Hours To Modify § 170.315(
                            <E T="01">a</E>
                            )(5) Demographics Criterion
                        </TTITLE>
                        <BOXHD>
                            <CHED H="1">Task</CHED>
                            <CHED H="1">Details</CHED>
                            <CHED H="1">Lower bound hours</CHED>
                            <CHED H="1">Upper bound hours</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1: Modify Sex [§ 170.315(a)(5)(i)(C)]</ENT>
                            <ENT>Value set for Sex removed and now references SNOMED CT</ENT>
                            <ENT>0</ENT>
                            <ENT>40</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2: Modify Sexual Orientation [§ 170.315(a)(5)(i)(D)]</ENT>
                            <ENT>Value set for Sexual Orientation removed and now references SNOMED CT</ENT>
                            <ENT>0</ENT>
                            <ENT>40</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 3: Modify Gender Identity [§ 170.315(a)(5)(i)(E)]</ENT>
                            <ENT>Value set for Gender Identity removed and now references SNOMED CT</ENT>
                            <ENT>0</ENT>
                            <ENT>40</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 4: Add Sex Parameter for Clinical Use [§ 170.315(a)(5)(i)(F)]</ENT>
                            <ENT>Add “Sex Parameter for Clinical Use” using LOINC</ENT>
                            <ENT>240</ENT>
                            <ENT>580</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 5: Add Pronouns [§ 170.315(a)(5)(i)(H)]</ENT>
                            <ENT>Add “Pronouns” using LOINC</ENT>
                            <ENT>240</ENT>
                            <ENT>580</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 6: Add Name to Use [§ 170.315(a)(5)(i)(G)]</ENT>
                            <ENT>Add “Name to Use” as a kind of name field</ENT>
                            <ENT>240</ENT>
                            <ENT>580</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,12C,16C,12C">
                        <TTITLE>Table 24—Example Calculation for the Lower Bound Estimated Cost to Products To Perform Task 1 in Table 23 To Modify Demographics</TTITLE>
                        <TDESC>[2022 dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated labor hours</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="1">
                                Developer salary
                                <LI>(per hour)</LI>
                            </CHED>
                            <CHED H="1">Projected products</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1</ENT>
                            <ENT>200</ENT>
                            <ENT>$128</ENT>
                            <ENT>321</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22">Example calculation: 200 * $116 * 321 products = $7,447,200.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,12,12">
                        <TTITLE>Table 25—Total Cost To Modify Demographics</TTITLE>
                        <TDESC>[2022 dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated cost</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1 (321 products)</ENT>
                            <ENT>$0</ENT>
                            <ENT>$1,643,520</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2 (321 products)</ENT>
                            <ENT>0</ENT>
                            <ENT>1,643,520</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 3 (321 products)</ENT>
                            <ENT>0</ENT>
                            <ENT>1,643,520</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 4 (321 products)</ENT>
                            <ENT>9,861,120</ENT>
                            <ENT>23,831,040</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 5 (321 products)</ENT>
                            <ENT>9,861,120</ENT>
                            <ENT>23,831,040</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Task 6 (321 products)</ENT>
                            <ENT>9,861,120</ENT>
                            <ENT>23,831,040</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total (321 products and 261 developers)</ENT>
                            <ENT>29,583,360</ENT>
                            <ENT>76,423,680</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>The cost to a health IT developer to make the modifications to the “patient demographics and observations” criterion for their certified Health IT Modules will range from $92,160 to $238,080 per product, on average. Therefore, assuming 321 products overall and a labor rate of $128 per hour, we estimate that the total cost to all health IT developers will, on average, range from $30 million to $76 million. This will be a one-time cost to developers per product that is certified to the specified certification criterion.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>Improved recording of sexual orientation and gender identity in the medical record has multiple benefits. This has clinical benefits for patients in the immediate term as information related to gender identity and sexual orientation is critical for informing treatment. Additionally, advances in treatment may result from researchers having more reliable and accurate sexual orientation and gender identity data available. Not only will this benefit clinical care teams who are treating patients within a particular clinical setting, this will improve the interoperability of this data when shared electronically with the patient or the patient's authorized representative through the technology of their choosing or when shared electronically with a third party elected by the patient, such as an application developer, health care provider, or other entity.</P>
                    <P>The benefits of these modifications are not quantifiable at this time, but we expect the resulting improvements to interoperable exchange of health information to significantly benefit providers and patients and improve the quality of healthcare provided. Furthermore, having a patient's information recorded uniformly and available across their medical records would improve the patient's access to their information and ensure the information is available uniformly across technologies.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments specific to this update to the “demographics” criterion.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The final impact analysis is consistent with the proposed rulemaking. Cost estimates were updated to reflect wages of software developers as of 2022.
                    </P>
                    <HD SOURCE="HD3">Updates to Transitions of Care Certification Criterion in § 170.315(b)(1)</HD>
                    <P>
                        As discussed in section III.C.9 of this preamble, we proposed to modify the “transitions of care” certification criterion in § 170.315(b)(1). We proposed to replace the fixed value set for the USCDI data element Sex and instead enable health IT developers to represent sex with the standard adopted in § 170.207(n)(1) for the time-period up to and including December 31, 2025; or § 170.207(n)(2).
                        <PRTPAGE P="1418"/>
                    </P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 26 shows the estimated labor costs per product to modify the transitions of care criterion. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will incur the costs noted in Table 26.</P>
                    <P>2. We estimate that 281 products certified by 236 developers will be affected by our policy. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.</P>
                    <P>The estimate of 281 products certified by 236 developers is derived as follows. We estimate that, in total, 368 health IT developers will certify 502 health IT products impacted by this rulemaking. However, not all these developers and products certify the transitions of care criterion and need to meet the adopted requirements. As of the end of 2021, 64% of developers and 56% of products certified to the transitions of care criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the modifications to the criterion.</P>
                    <P>3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91. As noted previously, we have assumed that overhead costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including overhead costs is $128.</P>
                    <GPOTABLE COLS="4" OPTS="L2,nj,i1" CDEF="s35,r50,11,11">
                        <TTITLE>
                            Table 26—Estimated Labor Hours To Modify § 170.315(
                            <E T="01">b</E>
                            )(1) Transitions of Care Criterion
                        </TTITLE>
                        <BOXHD>
                            <CHED H="1">Task</CHED>
                            <CHED H="1">Details</CHED>
                            <CHED H="1">Lower bound hours</CHED>
                            <CHED H="1">Upper bound hours</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1: Modify Sex [§ 170.315(a)(5)(i)(C)]</ENT>
                            <ENT>Value set for Sex removed and now references SNOMED CT</ENT>
                            <ENT>0</ENT>
                            <ENT>40</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,11C,11C">
                        <TTITLE>Table 27—Total Cost To Modify Transitions of Care</TTITLE>
                        <TDESC>[2022 dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated cost</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Modify Sex (281 products)</ENT>
                            <ENT>$0</ENT>
                            <ENT>$1,438,720</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>The cost to a health IT developer to make the modifications to the transitions of care criterion for their certified Health IT Modules will range from $0 to $5,120 per product, on average. Therefore, assuming 281 products overall and a labor rate of $128 per hour, we estimate that the total cost to all health IT developers will, on average, range from $0 to $1.5 million. This will be a one-time cost to developers per product that is certified to the specified certification criterion.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>There are multiple benefits associated with having more granular information available related to improved recording of sexual orientation and gender identity. This has clinical benefits for patients in the immediate term as information related to gender identity and sexual orientation is critical for informing treatment. Additionally, advances in treatment may result from researchers having more reliable and accurate sexual orientation and gender identity data available. Not only will this benefit clinical care teams who are treating patients within a particular clinical setting, this will improve the interoperability of this data when shared electronically with the patient or the patient's caregiver through the technology of their choosing or when shared electronically with a third party elected by the patient, such as an application developer, health care provider, or other entity.</P>
                    <P>The benefits of these modifications are not quantifiable at this time, but we expect the resulting improvements to interoperable exchange of health information to significantly benefit providers and patients and improve the quality of healthcare provided. Furthermore, having a patient's information recorded uniformly and available across their medical records will improve the patient's access to their information and ensure the information is available uniformly across technologies.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments related to the impact analysis of updates to the Transitions of care criterion.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The final impact analysis is consistent with the proposed rulemaking. Cost estimates were updated to reflect wages of software developers as of 2022.
                    </P>
                    <HD SOURCE="HD3">Patient Right To Request a Restriction on Use or Disclosure</HD>
                    <P>As discussed in section III.C.10 of this preamble, we have finalized as proposed to modify the existing criterion in § 170.315(e)(1) to add a paragraph (iii) stating patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. This policy is standards agnostic for the implementation of functional requirements supporting workflows for a patient to exercise their right to request restrictions on certain uses and disclosures of their EHI and for a HIPAA covered entity, such as a clinician that transmits any health information in electronic form in connection with a HHS adopted standard transactions, to honor such request.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>The update to § 170.315(e)(1) includes a new technical functionality that provides patients (and their authorized representatives) the ability to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. This task has its own level of effort, and this estimate is detailed in Table 28 below and is based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 29 shows the estimated labor costs per product to modify § 170.315(e)(1). We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will incur the costs noted in Table 29.</P>
                    <P>
                        2. We estimate that 246 products certified by 210 developers will be affected by our proposal. These estimates are a subset of the total 
                        <PRTPAGE P="1419"/>
                        estimated health IT developers and certified products we estimated above.
                    </P>
                    <P>The estimate of 246 products certified by 210 developers is derived as follows. We estimate that, in total, 368 health IT developers will certify 502 health IT products impacted by this rulemaking. However, not all these developers and products certify § 170.315(e)(1) and need to meet the proposed requirements. As of the end of 2021, 57% of developers and 49% of products certified § 170.315(e)(1). We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the proposed modifications to the criterion.</P>
                    <P>3. According to the Month 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91. As noted previously, we have assumed that overhead costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including overhead costs is $128.</P>
                    <GPOTABLE COLS="5" OPTS="L2,nj,i1" CDEF="s50,r100,12,12,8">
                        <TTITLE>
                            Table 28—Estimated Labor Hours To Modify 170.315(
                            <E T="01">e</E>
                            )(1)
                        </TTITLE>
                        <BOXHD>
                            <CHED H="1">Task</CHED>
                            <CHED H="1">Details</CHED>
                            <CHED H="1">Lower bound hours</CHED>
                            <CHED H="1">Upper bound hours</CHED>
                            <CHED H="1">Remarks</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1: Add internet-based method for patients (and their authorized representatives) to request a restriction</ENT>
                            <ENT>New technical functionality to be added to criterion § 170.315(e)(1). This is a standards agnostic method. Developer may choose internet-based method of choice (e.g., free-text box, check boxes for applicable data classes, etc.)</ENT>
                            <ENT>240</ENT>
                            <ENT>580</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s50,12C,12C">
                        <TTITLE>
                            Table 29—Total Cost To Modify 170.315(
                            <E T="01">e</E>
                            )(1)
                        </TTITLE>
                        <TDESC>[2022 dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated cost</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1 (246 products)</ENT>
                            <ENT>$7,557,120</ENT>
                            <ENT>$18,263,040</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>The cost to a health IT developer to modify § 170.315(e)(1) for their Health IT Modules would range from $30,720 to $74,240 per product, on average. Therefore, assuming 246 products overall and a labor rate of $128 per hour, we estimate that the total cost to all health IT developers would, on average, range from $7.5 million to $18 million. This would be a one-time cost to developers per product that is certified to the specified certification criterion and would not be perpetual.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>In the ONC Cures Act Final Rule, we noted that the updated criteria in § 170.315(b)(7) and (b)(8) (“security tags—summary of care—send” and “security tags—summary of care—receive”) would benefit providers, patients, and ONC because it would support more complete records, contribute to patient safety, and enhance care coordination. We stated that implementing security tags enables providers to share patient records more effectively with sensitive information, thereby protecting patient privacy while still delivering actionable clinical content. We emphasized that health care providers already have processes and workflows to address their existing compliance obligations, which could be made more efficient and cost effective using health IT. We were, however, unable to quantify these benefits at the time because we did not have adequate information to support quantitative estimates (85 FR 25927).</P>
                    <P>Since we issued the ONC Cures Act Final Rule, the number of developers certified to the voluntary criteria in § 170.315(b)(7) and (b)(8) has increased, but it remains a small percentage of the total products certified. While we believe there will be similar benefits to patients and other covered entities from our policies in this rule to support privacy workflows, we similarly are limited in our ability to estimate such impact at this time.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments specific to this impact analysis of patient requested restrictions.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The final impact analysis was updated to reflect the final policy to include the ability for patients to request restrictions for their information in the “view, download, and transmit” criterion.
                    </P>
                    <HD SOURCE="HD3">Insights Condition and Maintenance of Certification Requirements</HD>
                    <P>The “Insights Condition” calls for developers of certified health IT to report for each applicable product on measures which focus on interoperability. For the initial requirements of the Insights Condition, ONC proposed nine measures that relate to individual access to electronic health information, clinical care information exchange, public health information exchange, and standards adoption and conformance.</P>
                    <HD SOURCE="HD3">Alternatives</HD>
                    <P>
                        Section 4002(c) of the Cures Act requires the creation of an Electronic Health Record (EHR) Reporting Program. We have chosen to implement the developer reporting through ONC's Health IT Certification Program to integrate this legislative mandate with other reporting requirements for developers of certified health IT as a Condition and Maintenance of Certification requirement. This approach is aligned with how we have interpreted other similar provisions of the Cures Act, and it is intended to maximize participation among developers of certified health IT while aligning participation with other requirements of the Program. Other alternatives to implementing this provision of the Cures Act could be to conduct a survey of developers of certified health IT to report on measures; however, such an effort would reflect only those developers who participated in the survey, thus limiting the generalizability of the results. A survey approach would also complicate ONC's ability to standardize developer results reporting and thus the quality and the rigor of the data would be affected. Thus, in order to be consistent with ONC's implementation of other Cures Act Condition and Maintenance of Certification requirements, to maximize the generalizability and accuracy of the data gathered through this effort, and to align it with other activities, we have chosen 
                        <PRTPAGE P="1420"/>
                        to implement the Condition and Maintenance of Certification through ONC's Health IT Certification Program.
                    </P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>
                        In calculating the cost of reporting each measure 
                        <E T="03">m</E>
                         we applied the following expression:
                    </P>
                    <FP SOURCE="FP-2">
                        <E T="03">Cm = #Hours × Wage × # of Developers</E>
                    </FP>
                    <P>
                        The data for each of the elements (
                        <E T="03">e.g.,</E>
                         #hours, wages, #developers) were extracted from various sources and there are assumptions associated with each element, which are described in this section.
                    </P>
                    <P>
                        The 
                        <E T="03">#Hours</E>
                         represents the labor hours it takes to produce measure 
                        <E T="03">m.</E>
                         The developers of certified health IT were asked the average number of hours they would need to develop and report a measure. Based on their reporting, we created a lower bound that represents 25% less than the reported number and an upper bound that represents 35% more than the reported number. We adjusted the number of hours required for developing each measure according to the difficulty level as ranked by developers of certified health IT.
                        <SU>297</SU>
                        <FTREF/>
                         We attributed more hours to skillful labor categories (from administrators to programmers and managers) than what was provided by developers as we believe these will be more accurate estimates.
                    </P>
                    <FTNT>
                        <P>
                            <SU>297</SU>
                             Blavin F., et al. 2020. Urban Institute. Electronic Health Record (EHR) Reporting Program: Developer-Reported Measures. Available at 
                            <E T="03">https://www.urban.org/sites/default/files/publication/105427/electronic-health-record-ehr-reporting-program-developer-reported-measures.pdf.</E>
                             Accessed March 16, 2023.
                        </P>
                    </FTNT>
                    <P>
                        The 
                        <E T="03">Wage</E>
                         represents hourly wage of a particular occupation needed to produce a measure. The wage estimates were extracted from the 2022 Bureau of Labor Statistics data and multiplied by two to account for administrative and other indirect costs, representing the median hourly wage of a software developer ($128) and a management analyst ($101) (the numbers incorporate other indirect costs of labor).
                        <SU>298</SU>
                        <FTREF/>
                         We assumed that the time used only by these occupations was sufficient for completing the task. The number of health IT developers is a function of the finalized small developer threshold and certified criteria requirements, which are described in more detail in section III.F.3 of this preamble under 
                        <E T="03">Associated Thresholds for Health IT Developers.</E>
                         We used data from the 2019 CMS Promoting Interoperability (PI) program and the Certified Health IT Product List to estimate the number of developers that would be reporting measures to the program. Per the finalized small developer threshold, developers whose certified health IT products were used by at least 50 hospitals, or 500 clinicians would have to report measures to the Program. In addition to having these minimum number of users across their certified health IT products, per the policy, we limited developers to those with products that certify to at least one of the following criteria associated with the adopted measures (see Table 30):
                    </P>
                    <FTNT>
                        <P>
                            <SU>298</SU>
                             See BLS at 
                            <E T="03">https://www.bls.gov/oes/current/oes_nat.htm.</E>
                             Accessed September 15, 2023.
                        </P>
                    </FTNT>
                    <FP SOURCE="FP-1">• Transitions of care § 170.315(b)(1)</FP>
                    <FP SOURCE="FP-1">• Clinical information reconciliation and incorporation § 170.315(b)(2)</FP>
                    <FP SOURCE="FP-1">• Transmission to immunization registry § 170.315(f)(1)</FP>
                    <FP SOURCE="FP-1">• View, download, and transmit to 3rd party § 170.315(e)(1)</FP>
                    <FP SOURCE="FP-1">• Standardized API for patient and population services § 170.315(g)(10)</FP>
                    <P>For each measure, the estimated the number of developers of certified health IT depended on whether developers' products certified to criteria associated with a particular measure (as shown in Table 31) and whether they meet the threshold requirement for a small developer.</P>
                    <GPOTABLE COLS="8" OPTS="L2,p7,7/8,i1" CDEF="s45,r40,12,17,8,8,8,8">
                        <TTITLE>Table 30—Estimated Number of Hours and Developers Associated for Each Measure </TTITLE>
                        <TDESC>[per developer]</TDESC>
                        <BOXHD>
                            <CHED H="1">Measure</CHED>
                            <CHED H="1">Related criterion</CHED>
                            <CHED H="1">
                                Estimated number of
                                <LI>applicable </LI>
                                <LI>developers </LI>
                                <LI>of certified </LI>
                                <LI>health IT</LI>
                                <LI>(no threshold)</LI>
                            </CHED>
                            <CHED H="1">
                                Estimated 
                                <LI>number of</LI>
                                <LI>applicable </LI>
                                <LI>developers </LI>
                                <LI>of certified </LI>
                                <LI>health IT</LI>
                                <LI>(threshold applied)</LI>
                            </CHED>
                            <CHED H="1">
                                Management analyst estimated hours
                                <LI>(per developer)</LI>
                            </CHED>
                            <CHED H="2">
                                Lower 
                                <LI>bound</LI>
                            </CHED>
                            <CHED H="2">
                                Upper 
                                <LI>bound</LI>
                            </CHED>
                            <CHED H="1">
                                Software developer estimated hours
                                <LI>(per developer)</LI>
                            </CHED>
                            <CHED H="2">
                                Lower 
                                <LI>bound</LI>
                            </CHED>
                            <CHED H="2">
                                Upper 
                                <LI>bound</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Individuals' Access to EHI</ENT>
                            <ENT>§ 170.315(e)(1); § 170.315(g)(10)</ENT>
                            <ENT>157</ENT>
                            <ENT>53</ENT>
                            <ENT>320</ENT>
                            <ENT>800</ENT>
                            <ENT>1,100</ENT>
                            <ENT>2,220</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Immunization Submission to IIS</ENT>
                            <ENT>§ 170.315(f)(1)</ENT>
                            <ENT>115</ENT>
                            <ENT>37</ENT>
                            <ENT>480</ENT>
                            <ENT>1,200</ENT>
                            <ENT>2,800</ENT>
                            <ENT>5,600</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Immunization History and Forecasts</ENT>
                            <ENT>§ 170.315(f)(1)</ENT>
                            <ENT>115</ENT>
                            <ENT>37</ENT>
                            <ENT>470</ENT>
                            <ENT>1,200</ENT>
                            <ENT>1,380</ENT>
                            <ENT>2,760</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">C-CDAs Reconciliation and Incorporation</ENT>
                            <ENT>§ 170.315(b)(1); § 170.315(b)(2)</ENT>
                            <ENT>171</ENT>
                            <ENT>56</ENT>
                            <ENT>400</ENT>
                            <ENT>1,400</ENT>
                            <ENT>3,200</ENT>
                            <ENT>8,700</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Apps Supported</ENT>
                            <ENT>§ 170.315(g)(10)</ENT>
                            <ENT>176</ENT>
                            <ENT>59</ENT>
                            <ENT>320</ENT>
                            <ENT>800</ENT>
                            <ENT>1,850</ENT>
                            <ENT>3,700</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Use of FHIR in in Apps</ENT>
                            <ENT>§ 170.315(g)(10)</ENT>
                            <ENT>176</ENT>
                            <ENT>59</ENT>
                            <ENT>400</ENT>
                            <ENT>1,000</ENT>
                            <ENT>2,300</ENT>
                            <ENT>4,600</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Use of FHIR Bulk Data Access</ENT>
                            <ENT>§ 170.315(g)(10)</ENT>
                            <ENT>176</ENT>
                            <ENT>59</ENT>
                            <ENT>400</ENT>
                            <ENT>1,000</ENT>
                            <ENT>2,300</ENT>
                            <ENT>4,600</ENT>
                        </ROW>
                        <TNOTE>Data Source: ONC analysis of 2019 CMS Promoting Interoperability Program Data &amp; CHPL.</TNOTE>
                    </GPOTABLE>
                    <P>
                        We decided the small developer thresholds based upon analyses we conducted of the 2019 CMS PI Program and Certified Health IT Product List. We examined the various alternatives for setting user thresholds based on the percentage of users and developers that would be represented and reporting measures, respectively in the Program (
                        <E T="03">see</E>
                         Table 31 below). The thresholds we decided upon maximize coverage and while not unduly disadvantaging smaller developers. The thresholds were determined based upon analysis of 2019 CMS PI program data and the CHPL data. The data from the CMS PI program included 4,209 non-federal acute hospitals and 691,381 clinicians who attested to the program. After limiting hospitals and clinicians to those using existing 2015 Edition certification criteria, the 2015 Edition Cures Update criteria, or a combination of the two; and to those products of developers who had certified to at least one of the criteria associated with the measures adopted in the Program (see Table 30), we ended up with 3,863 hospitals and 689,801 clinicians. For example, based upon a threshold of 50 hospitals, we would be able to include approximately 99% of all hospital users and the top 18 developers (based upon market share) while excluding the bottom 33 developers (based upon market share). This 99% value is based upon the percentage of users who are not exclusively using products from developers who meet the small developer threshold. Thus, in the case of a 50-hospital threshold, only 1.4% of hospital users are exclusively using 
                        <PRTPAGE P="1421"/>
                        products from small developers, and thus about 99% of the inpatient market is covered.
                    </P>
                    <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s50,12,12,12,12">
                        <TTITLE>Table 31—Thresholds Options at the Developer Level</TTITLE>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="1">
                                Estimated 
                                <LI>number of </LI>
                                <LI>
                                    users 
                                    <E T="03">only</E>
                                </LI>
                                <LI>using small developers</LI>
                            </CHED>
                            <CHED H="1">
                                Estimated 
                                <LI>% of </LI>
                                <LI>
                                    users 
                                    <E T="03">only</E>
                                </LI>
                                <LI>using small developers</LI>
                            </CHED>
                            <CHED H="1">
                                Estimated 
                                <LI>number of</LI>
                                <LI>small </LI>
                                <LI>developers</LI>
                            </CHED>
                            <CHED H="1">
                                Estimated 
                                <LI>number of</LI>
                                <LI>remaining </LI>
                                <LI>developers</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="22">Hospitals:</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Option (a) 100 Threshold</ENT>
                            <ENT>142</ENT>
                            <ENT>3.7</ENT>
                            <ENT>39</ENT>
                            <ENT>12</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Option (b) 50 Threshold</ENT>
                            <ENT>56</ENT>
                            <ENT>1.4</ENT>
                            <ENT>33</ENT>
                            <ENT>18</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22">Clinicians:</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Option (a) 2,000 Threshold</ENT>
                            <ENT>21,075</ENT>
                            <ENT>3.1</ENT>
                            <ENT>176</ENT>
                            <ENT>31</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Option (b) 1,000 Threshold</ENT>
                            <ENT>11,251</ENT>
                            <ENT>1.6</ENT>
                            <ENT>160</ENT>
                            <ENT>47</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Option (b) 500 Threshold</ENT>
                            <ENT>7,828</ENT>
                            <ENT>1.1</ENT>
                            <ENT>146</ENT>
                            <ENT>61</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>In calculating the aggregate cost of developing all measures, we applied the concept of economies of scope, where the total cost of production is not incrementally increasing in the number of measures, but it is rather attenuating. Specifically, the aggregate cost in this application is governed by the following expression: The total cost (TC) of producing measures 1 and 2 is the sum of producing the two measures separately minus the cost of producing them together.</P>
                    <P>
                        To calculate the cost of producing measures together, developers of certified health IT were asked during discussions to provide an estimate on the extent to which there would be an overlap in developing infrastructure between the measures published by the Urban Institute and level of difficulty by measure.
                        <SU>299</SU>
                        <FTREF/>
                         While some measures we have finalized differ from those the Urban Institute published, there is significant overlap across many of the measures, which would retain the validity of these estimates. The weighted average for selected measures suggested that there would be considerable overlap on the immunization measures (see Table 32). We note that for the incorporation measure, there is overlap between the proposed measure and the CMS PI Program Measure. We welcomed comments that provide us information on the level of perceived overlap so that we can adjust the estimates accordingly for the costs associated with that measure.
                    </P>
                    <FTNT>
                        <P>
                            <SU>299</SU>
                             Blavin F., et al. 2020. Urban Institute. Electronic Health Record (EHR) Reporting Program: Developer-Reported Measures. Available at 
                            <E T="03">https://www.urban.org/sites/default/files/publication/105427/electronic-health-record-ehr-reporting-program-developer-reported-measures.pdf.</E>
                             Accessed March 16, 2023.
                        </P>
                    </FTNT>
                    <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s150,12C">
                        <TTITLE>Table 32—Percent Overlap in Developing the Following Combination of Measures</TTITLE>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="1">Percent</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Immunization Submission to IIS and Immunization History and Forecasts</ENT>
                            <ENT>50</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>Additionally, we assessed that there will be a 10% overlap of developing infrastructure across all measures. We applied these rates accordingly when calculating the total cost of developing measures for the Insights Condition.</P>
                    <P>Following this approach, the aggregate cost estimates over a 10-year period to develop and report on these measures are presented by different alternatives associated with thresholds in Table 33. The first row shows the total cost assuming developers have at least 50 hospital or 500 clinician users, which generates the cost between $98 and $218 million. In addition to estimating the costs associated with the 50 hospitals or 500 clinician user thresholds, we also present the cost for two alternatives where the number of users for hospitals is 100 and for clinician ranges from 1000 to 2000. The total cost would be reduced by about a half compared to the previous specification because smaller number of developers would qualify for the Insights Condition.</P>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s50,12,12">
                        <TTITLE>Table 33—Aggregate Cost Estimates for the Insights Condition by Threshold Alternatives</TTITLE>
                        <BOXHD>
                            <CHED H="1">Options</CHED>
                            <CHED H="1">Lower bound</CHED>
                            <CHED H="1">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">50 Hospitals and 500 Clinicians Threshold (Proposed Approach)</ENT>
                            <ENT>$98,373,673</ENT>
                            <ENT>$218,671,106</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">100 Hospitals and 1000 Clinicians Threshold (Alternative 1)</ENT>
                            <ENT> 69,268,381</ENT>
                            <ENT> 153,852,086</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">100 Hospitals and 2000 Clinicians Threshold (Alternative 2)</ENT>
                            <ENT>47,638,637</ENT>
                            <ENT>105,007,568</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">No Threshold Applied</ENT>
                            <ENT>297,027,045</ENT>
                            <ENT>660,807,830</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>In Table 30, we present the estimated number of labor hours to develop and report by measure for each individual developer. This table served as the basis for the cost estimates, prior to adjusting as described above.</P>
                    <P>
                        In Table 34, we present cost estimates for each individual measure by developer and across all developers. The measures vary in cost because we made adjustments based on synergies discussed above (
                        <E T="03">e.g.,</E>
                         similar measures, common infrastructure) and the level of 
                        <PRTPAGE P="1422"/>
                        expected burden to develop each measure.
                    </P>
                    <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s50,15,12,12,12,12">
                        <TTITLE>Table 34—Estimated Costs by Measure per Developer of Certified Health IT and Across All Eligible Developers of Certified Health IT</TTITLE>
                        <TDESC>[No threshold]</TDESC>
                        <BOXHD>
                            <CHED H="1">Measure</CHED>
                            <CHED H="1">
                                Number eligible 
                                <LI>developers</LI>
                            </CHED>
                            <CHED H="1">
                                Estimated costs
                                <LI>(per developer)</LI>
                            </CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                            <CHED H="1">
                                Total estimated costs
                                <LI>(all eligible developers)</LI>
                            </CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Individuals' Access to EHI</ENT>
                            <ENT>157</ENT>
                            <ENT>$169,924</ENT>
                            <ENT>$353,846</ENT>
                            <ENT>$26,678,005</ENT>
                            <ENT>$55,553,791</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Immunization Submission to IIS</ENT>
                            <ENT>115</ENT>
                            <ENT>360,023</ENT>
                            <ENT>739,508</ENT>
                            <ENT>41,425,606</ENT>
                            <ENT>85,043,311</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Immunization History and Forecasts</ENT>
                            <ENT>115</ENT>
                            <ENT>109,227</ENT>
                            <ENT>228,908</ENT>
                            <ENT>12,561,105</ENT>
                            <ENT>26,324,363</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">C-CDAs Reconciliation and Incorporation</ENT>
                            <ENT>171</ENT>
                            <ENT>402,305</ENT>
                            <ENT>1,116,610</ENT>
                            <ENT>68,794,070</ENT>
                            <ENT>190,940,267</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Applications Supported</ENT>
                            <ENT>176</ENT>
                            <ENT>238,088</ENT>
                            <ENT>488,773</ENT>
                            <ENT>41,903,326</ENT>
                            <ENT>86,024,030</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Use of FHIR in Apps</ENT>
                            <ENT>176</ENT>
                            <ENT>300,186</ENT>
                            <ENT>616,256</ENT>
                            <ENT>52,832,657</ENT>
                            <ENT>108,461,034</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Use of FHIR Bulk Data Access</ENT>
                            <ENT>176</ENT>
                            <ENT>300,186</ENT>
                            <ENT>616,256</ENT>
                            <ENT>52,832,567</ENT>
                            <ENT>108,461,034</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">All Measures: Total Cost</ENT>
                            <ENT/>
                            <ENT>1,880,136</ENT>
                            <ENT>4,160,155</ENT>
                            <ENT>297,027,425</ENT>
                            <ENT>660,807,830</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s50,15,12,12,12,12">
                        <TTITLE>Table 35—Estimated Costs by Measure per Developer of Certified Health IT and Across All Eligible Developers of Certified Health IT </TTITLE>
                        <TDESC>[Threshold applied]</TDESC>
                        <BOXHD>
                            <CHED H="1">Measure</CHED>
                            <CHED H="1">
                                Number eligible 
                                <LI>developers</LI>
                            </CHED>
                            <CHED H="1">
                                Estimated costs
                                <LI>(per developer)</LI>
                            </CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                            <CHED H="1">
                                Total estimated costs
                                <LI>(all eligible developers)</LI>
                            </CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Individuals' Access to EHI</ENT>
                            <ENT>53</ENT>
                            <ENT>$169,924</ENT>
                            <ENT>$353,846</ENT>
                            <ENT>$9,005,951</ENT>
                            <ENT>$18,753,827</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Immunization Submission to IIS</ENT>
                            <ENT>37</ENT>
                            <ENT>260,223</ENT>
                            <ENT>739,508</ENT>
                            <ENT>13,328,238</ENT>
                            <ENT>27,361,761</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Immunization History and Forecasts</ENT>
                            <ENT>37</ENT>
                            <ENT>109,227</ENT>
                            <ENT>228,908</ENT>
                            <ENT>4,041,399</ENT>
                            <ENT>8,469,578</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">C-CDAs Reconciliation and Incorporation</ENT>
                            <ENT>56</ENT>
                            <ENT>402,305</ENT>
                            <ENT>1,116,610</ENT>
                            <ENT>22,529,052</ENT>
                            <ENT>62,530,146</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Apps Supported</ENT>
                            <ENT>59</ENT>
                            <ENT>238,088</ENT>
                            <ENT>488,773</ENT>
                            <ENT>14,047,138</ENT>
                            <ENT>28,837,601</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Use of FHIR in Apps</ENT>
                            <ENT>59</ENT>
                            <ENT>300,186</ENT>
                            <ENT>616,256</ENT>
                            <ENT>17,710,948</ENT>
                            <ENT>36,359,097</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Use of FHIR Bulk Data Access</ENT>
                            <ENT>59</ENT>
                            <ENT>300,186</ENT>
                            <ENT>616,256</ENT>
                            <ENT>17,710,948</ENT>
                            <ENT>36,359,097</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">All Measures: Total Cost</ENT>
                            <ENT/>
                            <ENT>1,880,136</ENT>
                            <ENT>4,160,1550</ENT>
                            <ENT>98,373,673</ENT>
                            <ENT>218,671,106</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>For the Insights Condition of Certification, we have indicated that developers of certified health IT who were required to report for Insights could leverage relevant Insights measures for real world testing annual reporting. We recognize some overlap in the two Conditions of Certification and that Insights measures would be appropriate to meet real world testing requirements for applicable certification criteria. An analysis of the CHPL shows that among developers required to report for Insights, 25% to 50% of their real world testing reporting requirements could be satisfied leveraging Insights metrics. Considering this we estimate that 25% to 50% of an average developer's annual real world testing costs could be saved by using Insights reporting as part of their real world testing plans.</P>
                    <P>We estimated cost savings for developers required to report for Insights. Cost savings were modeled using the real world testing cost estimates we have finalized in the ONC Cures Final Rule. We estimated in that final rule that a developer, on average, would face annual costs of $109,557 (2017 dollars) to meet real world testing reporting requirements. In 2022 dollars, we estimate this is $130,811 in annual costs. In Table 36 we show the impact of these cost savings on the total 10-year cost of developers to meet Insights requirements. We estimate this flexibility in meeting both Insights and real world testing reporting requirements will yield $13.6 million to $27.4 million in cost savings in total. We estimate these costs savings will reduce the overall total cost of developers reporting for Insights. The total cost of Insights is estimated to be $84.7 million to $191.2 million.</P>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,14,15">
                        <TTITLE>Table 36—Estimated Cost Savings From Reporting for Both Real World Testing and Insights</TTITLE>
                        <BOXHD>
                            <CHED H="1">Options</CHED>
                            <CHED H="1">Lower bound</CHED>
                            <CHED H="1">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">50 Hospitals and 500 Clinicians Threshold (No Cost Savings applied)</ENT>
                            <ENT>$98,373,673</ENT>
                            <ENT>$218,671,106</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">50 Hospitals and 500 Clinicians Threshold (Cost Savings applied)</ENT>
                            <ENT>84,735,783</ENT>
                            <ENT>191,233,443</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        The ONC Cures Act Final Rule seeks to advance interoperability and support the access, exchange, and use of electronic health information. There is currently limited transparency and information regarding interoperability; this not only stymies informed decision-making by ONC but also others in the industry, including health care providers, and entities that enable 
                        <PRTPAGE P="1423"/>
                        exchange, including various types of health information networks and health app developers. ONC's measurement of interoperability is currently reliant primarily on self-reported survey data from end users of health information technology. While this information does provide some insights on interoperability from end-user perspectives, the insights derived are limited. The adopted measures will provide system-generated metrics on interoperability that will complement self-reported, user perspective data sources, such as surveys. Through the Insights Condition section of this final rule, we have identified where surveys have been limited in providing a clear picture of certain aspects of interoperability that these measures will elucidate. In addition, they will reach a greater number of health care providers than surveys, giving a more complete and representative national perspective. Greater transparency and information on interoperability of health IT products has the potential to benefit several interested parties, including ONC and other entities that enable exchange, including health app developers and health information networks. The adopted measures are also designed to identify areas that are working well and problems that we can monitor over time. This will help identify the need for technical and policy solutions as well as spur innovation that builds on successes and addresses gaps. While we currently do not have a means to quantify these benefits, we welcomed any feedback on methods to better quantify the impact these measures can have for healthcare and health IT.
                    </P>
                    <P>The measures in this final rule for the Insights Condition will help improve and inform ONC programmatic and regulatory decision-making. ONC's programs and policies are designed to make direct and positive impacts on health IT use, care delivery, and patient health. ONC does this primarily through supporting standards development and the Program. The adopted measures will help ONC and others better understand the use, progress, and value of health IT standards. This has practical implications for improving the work ONC leads that increases the use of standards. For example, ONC has limited empirical information to provide guidance on the usage of standards associated with the Interoperability Standards Advisory. With the addition of the adopted measures, ONC can provide guidance to industry that is grounded in data from health IT developers rather than anecdotes. This has the potential to move industry to adopt standards more quickly, which has downstream impacts on improved interoperability. In addition, the adopted measures will increase transparency regarding the capability and usage of certified products. Through these measures, ONC and other interested parties will be able to identify areas that are problematic and in need of further investigation, such as cross-cutting policy and technical issues. They will also provide needed data to develop solutions to these complex problems.</P>
                    <P>
                        The adopted measures from the Insights Condition will focus on four key priority areas: individual access to electronic health information, clinical care information exchange, standards adoption and conformance, and public health information exchange. Under the individuals' access to electronic health information measurement area, the measure will inform on the ONC Cures Act Final Rule goal of increasing access of electronic health information to individuals, particularly through the use of third-party apps. Increased patient engagement has been associated with improved health outcomes, and improved ease of access to their own medical records can improve patient engagement.
                        <SU>300</SU>
                        <FTREF/>
                         Thus, a better understanding of how patients are using apps through certified health IT will help inform ONC and other interested parties on the progress to reaching this goal. In addition, this measure will help inform app developers and developers of certified health IT, who are supporting apps on what individual's needs are to access their EHI. It will also inform health care provider organizations regarding action they may need to consider in supporting EHI and the need for outreach to patients and caregivers.
                    </P>
                    <FTNT>
                        <P>
                            <SU>300</SU>
                             Health Affairs. (2013). Health Policy Brief: Patient Engagement. Accessed March 16, 2023, at: 
                            <E T="03">http://healthaffairs.org/healthpolicybriefs/brief_pdfs/healthpolicybrief_86.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        The clinical care information exchange measure will help ONC and other interested parties better understand the volume of information exchanged using C-CDA documents and how the information exchange is subsequently used via incorporation and reconciliation. Understanding the rates of C-CDA document incorporation is valuable for interested parties supporting C-CDA document exchange (
                        <E T="03">e.g.,</E>
                         is it incorporated and used). This measure can also support further development in the incorporation of C-CDA documents.
                    </P>
                    <P>
                        Currently, ONC has limited data on the use of certified API technology in the app market. The ONC Cures Act Final Rule established the rules for the use of certified API technology in such a way to increase access to health information for both patients and health care providers. By understanding which apps are using FHIR-based APIs and the volume of transfer of FHIR resources, ONC and standards development organizations (SDOs) will be able to prioritize their work toward high-use data elements as well as explore why some data elements may not have as much use as anticipated. This will not only benefit ONC and SDOs, but in the long-term this will benefit patient care as exchange at the data element level is likely to be less cumbersome than document-based exchange. In addition, these measures are expected to increase transparency in the health IT app market which should lead to improved efficiencies, more competition, and better use of data. Greater transparency will inform decision-making among app developers, patients, health care providers, and other key parties (
                        <E T="03">e.g.,</E>
                         CARIN Alliance). Through better insights into the intersections of health IT and the app market, gaps as well as areas of strength can be identified that may spur further innovations in the market.
                    </P>
                    <P>The ONC Cures Act Final Rule also introduced certification criteria and policies for the exchange of bulk patient health information. The goal of these functionalities is to make patient data requests easier and less expensive as well as allow health care providers a greater choice of health IT applications. Understanding how these functionalities are being used will allow ONC and others to assess the progress toward those goals and identify where there may be areas in need of refinement. It will provide interested parties, such as Accountable Care Organizations (ACO), researchers, and others with interest in secondary use of certified health IT data with insights as to whether such data is easily moved out of health IT products to support a variety of use cases to advance patient care.</P>
                    <P>
                        Finally, because of the COVID-19 epidemic, there has been increased attention on the capabilities of health care providers to share public health information with public health agencies (PHA).
                        <SU>301</SU>
                        <FTREF/>
                         There has been a focus on the electronic exchange of immunization data to an immunization information system (IIS) via certified health IT. The 
                        <PRTPAGE P="1424"/>
                        adopted measures will identify trends and patterns in IIS' ability to receive immunization data to enable innovative solutions and improve the utility of IIS' and IIS data. Thus, this data would be beneficial to IIS registries to help make improvements to their systems and policies to better support exchange of immunization data. In addition, these measures can help support the numerous HHS efforts aimed at improving the flow of information between health care providers and PHAs, such as ONC's STAR HIE Program and the CDC's ongoing Data Modernization Initiative.
                    </P>
                    <FTNT>
                        <P>
                            <SU>301</SU>
                             Dixon BE, Caine VA, Halverson PK. Deficient Response to COVID-19 Makes the Case for Evolving the Public Health System. American Journal of Preventive Medicine. 2020;59(6):887-891. 
                            <E T="03">https://doi.org/10.1016/j.amepre.2020.07.024.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive specific comments related to the Insights impact analysis. Commenters did, however, raise general concerns about the overall cost of the rulemaking, including costs estimated for Insights.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We updated the Insights impact analysis based upon updates to the condition of certification, as adopted in this final rule. The impact analysis reflects reduced costs, as well as cost savings, to implement this finalized Condition of Certification.
                    </P>
                    <HD SOURCE="HD3">Information Blocking Enhancements</HD>
                    <P>We proposed in section IV of this preamble several enhancements with respect to the information blocking provisions in the ONC Cures Act Final Rule. These include defining in regulation text what it means, and what it does not mean, to “offer” health IT. The enhancements also include updating the Infeasibility (45 CFR 171.204) and Manner (45 CFR 171.301, formerly known as the “Content and Manner”) Exceptions for clarity and to add more ways for actors' practices to satisfy these exceptions and thus not be considered “information blocking” for purposes of 45 CFR part 171.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>
                        We expect ONC to incur an annual cost for issuing educational resources related to the proposed information blocking enhancements. We estimate that ONC would issue educational resources each quarter, or at least four times per year. We assume that the resources would be provided by ONC staff with the expertise of a GS-15, Step 1 federal employee(s). The hourly wage with benefits for a GS-15, Step 1 employee located in Washington, DC is approximately $142.
                        <SU>302</SU>
                        <FTREF/>
                         We estimate it would take ONC staff between 100 and 200 hours to develop resources each quarter, or 400 to 800 hours annually. Therefore, we estimate the annual cost to ONC would, on average, range from $56,800 to $113,600.
                    </P>
                    <FTNT>
                        <P>
                            <SU>302</SU>
                             Office of Personnel and Management. 
                            <E T="03">https://www.opm.gov/policy-data-oversight/pay-leave/salaries-wages/salary-tables/pdf/2022/DCB.pdf.</E>
                             Accessed March 16, 2023.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>Currently, ONC has limited data and research available to reasonably estimate the benefits of how often an actor may avail itself of one of the permitted exceptions or the costs for an actor to meet a condition to an exception.</P>
                    <P>We anticipate that the adopted information blocking enhancements will enable actors to determine more easily and with greater certainty whether their practices (acts or omissions) that may or do interfere with access, exchange, or use of EHI (as defined in 45 CFR 171.102) meet the conditions to be considered a “reasonable and necessary” activity under an information blocking exception. As such, we expect these policies will further ease the burden and costs of complying with the information blocking regulations, while providing increased predictability. This predictability will permit regulated entities to plan and invest resources in developing and using interoperable technologies and services to improve healthcare efficiency and value more effectively. Additionally, we anticipate as a result of the revised definitions and exceptions, there will be reduced interference with the access, exchange, and use of electronic health information because of the added clarity the policies will provide the market regarding certain practices. Thus, we anticipate an increase in the overall benefits derived from reducing the prevalence of information blocking. We welcomed comment on these conclusions and the supporting rationale.</P>
                    <HD SOURCE="HD3">Total Annual Cost Estimate</HD>
                    <P>We estimate that the total annual cost for this final rule for the first year after it is finalized (including one-time costs), based on the cost estimates outlined above and throughout this RIA, would result in $437 million. The total undiscounted perpetual cost over a 10-year period for this final rule (starting in year two), based on the cost estimates outlined above, would result in $477 million. We estimate the total costs to health IT developers to be $914 million while the government (ONC) costs to be between $56,800 to $113,600.</P>
                    <HD SOURCE="HD3">Total Annual Benefit Estimate</HD>
                    <P>We estimate the total annual benefit for this final rule, based on the benefit estimates outlined above, would be on average $1.0 billion.</P>
                    <HD SOURCE="HD3">Total Annual Net Benefit</HD>
                    <P>We estimate the total undiscounted perpetual annual net benefit for this final rule (starting in year three), based on the estimates outlined above, would result in a net benefit of $124 million.</P>
                    <HD SOURCE="HD3">b. Accounting Statement and Table</HD>
                    <P>When a rule is considered significant under Section 3(f)(1) under Executive Order 12866 and E.O. 14094, we are required to develop an accounting statement indicating the classification of the expenditures associated with the provisions of the final rule. Monetary annual effects are presented as discounted flows using 3% and 7% factors in Table 38 below. We are not able to explicitly define the universe of all costs but have provided an average of likely costs of this final rule as well as a high and low range of likely costs.</P>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,14,14">
                        <TTITLE>Table 37—E.O. 12866 Summary Table</TTITLE>
                        <TDESC>[2022 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="1">
                                Primary
                                <LI>(3%)</LI>
                            </CHED>
                            <CHED H="1">
                                Primary
                                <LI>(7%)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Present Value of Quantified Costs</ENT>
                            <ENT>$853,114,341</ENT>
                            <ENT>$784,445,719</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Present Value of Quantified Benefits</ENT>
                            <ENT>829,421,937</ENT>
                            <ENT>623,925,956</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Present Value of Net Benefits</ENT>
                            <ENT>23,692,404</ENT>
                            <ENT>160,519,763</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Annualized Quantified Costs</ENT>
                            <ENT>100,011,026</ENT>
                            <ENT>111,687,422</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Annualized Quantified Benefits</ENT>
                            <ENT>103,155,077</ENT>
                            <ENT>101,704,924</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Annualized Net Quantified Benefits</ENT>
                            <ENT>3,144,051</ENT>
                            <ENT>9,982,498</ENT>
                        </ROW>
                    </GPOTABLE>
                    <PRTPAGE P="1425"/>
                    <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s50,11,11,11,11,11">
                        <TTITLE>Table 38—E.O. 12866 Summary Table Non-Discounted Flows</TTITLE>
                        <TDESC>[2022 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="1">Year 1</CHED>
                            <CHED H="1">Year 2</CHED>
                            <CHED H="1">Year 3</CHED>
                            <CHED H="1">Year 4</CHED>
                            <CHED H="1">Year 5</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Costs</ENT>
                            <ENT>$437,500,845</ENT>
                            <ENT>$264,945,762</ENT>
                            <ENT>$50,769,243</ENT>
                            <ENT>$31,235,512</ENT>
                            <ENT>$21,692,039</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">Benefits</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT>28,850,000</ENT>
                            <ENT>57,700,000</ENT>
                            <ENT>86,550,000</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="25"> </ENT>
                            <ENT>Year 6</ENT>
                            <ENT>Year 7</ENT>
                            <ENT>Year 8</ENT>
                            <ENT>Year 9</ENT>
                            <ENT>Year 10</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Costs</ENT>
                            <ENT>21,692,039</ENT>
                            <ENT>21,692,039</ENT>
                            <ENT>21,692,039</ENT>
                            <ENT>21,692,039</ENT>
                            <ENT>21,692,039</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Benefits</ENT>
                            <ENT>115,400,000</ENT>
                            <ENT>144,250,000</ENT>
                            <ENT>173,100,000</ENT>
                            <ENT>201,950,000</ENT>
                            <ENT>230,800,000</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD2">D. Regulatory Flexibility Act</HD>
                    <P>The Regulatory Flexibility Act (RFA) requires agencies to analyze options for regulatory relief of small entities, if a rule has a significant impact on a substantial number of small entities.</P>
                    <P>
                        The Small Business Administration (SBA) establishes the size of small businesses for Federal Government programs based on average annual receipts or the average employment of a firm.
                        <SU>303</SU>
                        <FTREF/>
                         The entities that are likely to be directly affected by the requirements in this final rule requirements are health IT developers. We note that the finalized updates and clarifications to the reasonable and necessary activities that do not constitute information blocking will provide flexibilities and relief for health IT developers of certified health IT, health information networks, health information exchanges, and health care providers in relation to the information blocking provision of the Cures Act. We welcomed comments on the impact of our information blocking-related proposals on small entities.
                    </P>
                    <FTNT>
                        <P>
                            <SU>303</SU>
                             The SBA references that annual receipts mean “total income” (or in the case of a sole proprietorship, “gross income”) plus “cost of goods sold” as these terms are defined and reported on Internal Revenue Service tax return forms.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments on our approach.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized as proposed.
                    </P>
                    <P>
                        While health IT developers that pursue certification of their health IT under the Program represent a small segment of the overall information technology industry, we believe that many health IT developers impacted by the requirements adopted in this final rule most likely fall under the North American Industry Classification System (NAICS) code 541511 “Custom Computer Programming Services.” 
                        <SU>304</SU>
                        <FTREF/>
                         OMB advised that the Federal statistical establishment data published for reference years beginning on or after January 1, 2022, should be published using the 2022 NAICS United States codes.
                        <SU>305</SU>
                        <FTREF/>
                         The SBA size standard associated with this NAICS code is set at $34 million annual receipts or less. There is enough data generally available to establish that between 75% and 90% of entities that are categorized under the NAICS code 541511 are under the SBA size standard. We also note that with the exception of aggregate business information available through the U.S. Census Bureau and the SBA related to NAICS code 541511, it appears that many health IT developers that pursue certification of their health IT under the Program are privately held or owned and do not regularly, if at all, make their specific annual receipts publicly available. As a result, it is difficult to locate empirical data related to many of these health IT developers to correlate to the SBA size standard. However, although not perfectly correlated to the size standard for NAICS code 541511, we do have information indicating that over 60% of health IT developers that have had Complete EHRs and/or Health IT Modules certified to the 2011 Edition have less than 51 employees.
                    </P>
                    <FTNT>
                        <P>
                            <SU>304</SU>
                             
                            <E T="03">https://www.sba.gov/sites/sbagov/files/2023-06/Table%20of%20Size%20Standardslowbar;Effective%20March%2017%2C%202023%20%282%29.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>305</SU>
                             
                            <E T="03">https://www.sba.gov/article/2022/feb/01/guidance-using-naics-2022-procurement.</E>
                        </P>
                    </FTNT>
                    <P>We estimate that the finalized requirements in this final rule will have effects on health IT developers, some of which may be small entities, that have certified health IT or are likely to pursue certification of their health IT under the Program. We believe, however, that we have adopted the minimum number of requirements necessary to accomplish our primary policy goal of enhancing interoperability. Further, as discussed in this RIA above, there are very few appropriate regulatory or non-regulatory alternatives that could be developed to lessen the compliance burden associated with this final rule because at least a few of the policies are derived directly from legislative mandates in the Cures Act.</P>
                    <P>We do not believe that the finalized requirements of this final rule will create a significant impact on a substantial number of small entities and we received no comments on whether there are small entities that we have not identified that may be affected in a significant way. The Predictive DSI policy within the criterion adopted in the criterion at § 170.315(b)(11) and the Insights condition of certification represent the highest potential costs for health IT developers in our estimates. The finalized Decision Support Interventions policy establishes different requirements for developers of certified health IT that supply Predictive DSIs than those developers that do not supply Predictive DSIs. Many developers who do not supply a Predictive DSI as part of their Health IT Module are among those developers with smaller revenues and fewer clients. These developers will be able to certify to the criterion at § 170.315(b)(11) while expending limited additional development resources on products they have certified currently. Specifically, these developers will likely have little to no costs related to providing complete and up-to-date source attribute information for Predictive DSI supplied by the developer or engaging in risk management and annually update risk management information. Furthermore, the Insights Condition of Certification excludes small entities from reporting on the finalized measures. Small entities will face no additional costs for meeting the finalized measures, as described in the final policy and RIA for the Insights Condition.</P>
                    <P>The Secretary certifies that this final rule will not have a significant impact on a substantial number of small entities.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized as proposed.
                    </P>
                    <HD SOURCE="HD2">E. Executive Order 13132—Federalism</HD>
                    <P>
                        Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a final rule) that imposes substantial direct requirement costs on state and local governments, preempts state law, or otherwise has federalism implications. 
                        <PRTPAGE P="1426"/>
                        Nothing in this final rule imposes substantial direct compliance costs on state and local governments, preempts state law, or otherwise has federalism implications. We are not aware of any state laws or regulations that are contradicted or impeded by any of the policies in this final rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized as proposed.
                    </P>
                    <HD SOURCE="HD2">F. Unfunded Mandates Reform Act of 1995</HD>
                    <P>Section 202 of the Unfunded Mandates Reform Act of 1995 requires that agencies assess anticipated costs and benefits before issuing any rule that imposes unfunded mandates on state, local, and tribal governments or the private sector requiring spending in any one year of $100 million in 1995 dollars, updated annually for inflation. The current inflation-adjusted statutory threshold is approximately $177 million in 2023. While the estimated potential cost effects of this final rule reach the statutory threshold, we do not believe this final rule imposes unfunded mandates on state, local, and tribal governments, or the private sector.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized as proposed.
                    </P>
                    <P>OMB reviewed this final rule.</P>
                    <LSTSUB>
                        <HD SOURCE="HED">List of Subjects</HD>
                        <CFR>45 CFR Part 170</CFR>
                        <P>Computer technology, Electronic health record, Electronic information system, Electronic transactions, Health, Healthcare, Health information technology, Health insurance, Health records, Hospitals, Incorporation by reference, Laboratories, Medicaid, Medicare, Privacy, Reporting and record keeping requirements, Public health, Security.</P>
                        <CFR>45 CFR Part 171</CFR>
                        <P>Computer technology, Electronic health record, Electronic information system, Electronic transactions, Health, Healthcare, Health care provider, Health information exchange, Health information technology, Health information network, Health insurance, Health records, Hospitals, Privacy, Reporting and recordkeeping requirements, Public health, Security.</P>
                    </LSTSUB>
                    <P>For the reasons set forth in the preamble, 45 CFR subtitle A, subchapter D, is amended as follows:</P>
                    <PART>
                        <HD SOURCE="HED">PART 170—HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY</HD>
                    </PART>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>1. The authority citation for part 170 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority: </HD>
                            <P>42 U.S.C. 300jj-11; 42 U.S.C 300jj-14; 5 U.S.C. 553.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>2. Amend § 170.102 by:</AMDPAR>
                        <AMDPAR>a. Removing definitions for “2015 Edition Base EHR” and “2015 Edition health IT certification criteria”; and</AMDPAR>
                        <AMDPAR>b. Adding definitions for “Base EHR”, “ONC certification criteria for health IT”, “Predictive Decision Support Intervention”, “Provide”, and “Revised certification criterion (or criteria)” in alphabetical order.</AMDPAR>
                        <P>The additions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.102 </SECTNO>
                            <SUBJECT>Definitions.</SUBJECT>
                            <P>
                                <E T="03">Base EHR</E>
                                 means an electronic record of health-related information on an individual that:
                            </P>
                            <P>(1) Includes patient demographic and clinical health information, such as medical history and problem lists;</P>
                            <P>(2) Has the capacity:</P>
                            <P>(i) To provide clinical decision support;</P>
                            <P>(ii) To support physician order entry;</P>
                            <P>(iii) To capture and query information relevant to healthcare quality;</P>
                            <P>(iv) To exchange electronic health information with, and integrate such information from other sources; and</P>
                            <P>(3) Has been certified to the certification criteria adopted by the Secretary in—</P>
                            <P>(i) Section 170.315(a)(1), (2), or (3); (a)(5) and (14), (b)(1), (c)(1), and (g)(7), (9), (10); and (h)(1) or (2);</P>
                            <P>(ii) Section 170.315(a)(9) or (b)(11) for the period up to and including December 31, 2024; and</P>
                            <P>(iii) Section 170.315(b)(11) on and after January 1, 2025.</P>
                            <STARS/>
                            <P>
                                <E T="03">ONC certification criteria for health IT</E>
                                 means the certification criteria in § 170.315.
                            </P>
                            <STARS/>
                            <P>
                                <E T="03">Predictive Decision Support Intervention or Predictive DSI</E>
                                 means technology that supports decision-making based on algorithms or models that derive relationships from training data and then produces an output that results in prediction, classification, recommendation, evaluation, or analysis.
                            </P>
                            <STARS/>
                            <P>
                                <E T="03">Provide</E>
                                 means the action or actions taken by a developer of certified Health IT Modules to make the certified health IT available to its customers.
                            </P>
                            <STARS/>
                            <P>
                                <E T="03">Revised certification criterion (or criteria)</E>
                                 means a certification criterion that meets at least one of the following:
                            </P>
                            <P>(1) Has added or changed the capabilities described in the existing criterion in this part;</P>
                            <P>(2) Has an added or changed standard or implementation specification referenced in the existing criterion in this part; or</P>
                            <P>(3) Is specified through notice and comment rulemaking as an iterative or replacement version of an existing criterion in this part.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>3. Amend § 170.205 by:</AMDPAR>
                        <AMDPAR>a. Revising paragraph (a)(5); and</AMDPAR>
                        <AMDPAR>b. Adding paragraphs (a)(6) and (t).</AMDPAR>
                        <P>The revision and additions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.205 </SECTNO>
                            <SUBJECT>Content exchange standards and implementation specifications for exchanging electronic health information.</SUBJECT>
                            <P>(a) * * *</P>
                            <P>
                                (5) 
                                <E T="03">Standard.</E>
                                 HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 (incorporated by reference, see § 170.299). The adoption of this standard expires on January 1, 2026.
                            </P>
                            <P>
                                (6) 
                                <E T="03">Standard.</E>
                                 HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1—US Realm (incorporated by reference, see § 170.299).
                            </P>
                            <STARS/>
                            <P>
                                (t) 
                                <E T="03">Public health—electronic case reporting—</E>
                                (1) 
                                <E T="03">Standard.</E>
                                 HL7® FHIR® Implementation Guide: Electronic Case Reporting (eCR)—US Realm 2.1.0—STU 2 US (HL7 FHIR eCR IG) (incorporated by reference, see § 170.299).
                            </P>
                            <P>
                                (2) 
                                <E T="03">Standard.</E>
                                 HL7 CDA® R2 Implementation Guide: Public Health Case Report—the Electronic Initial Case Report (eICR) Release 2, STU Release 3.1—US Realm (HL7 CDA eICR IG) (incorporated by reference, see § 170.299).
                            </P>
                            <P>
                                (3) 
                                <E T="03">Standard.</E>
                                 HL7® CDA® R2 Implementation Guide: Reportability Response, Release 1, STU Release 1.1—US Realm (HL7 CDA RR IG) (incorporated by reference, see § 170.299).
                            </P>
                            <P>
                                (4) 
                                <E T="03">Standard.</E>
                                 Reportable Conditions Trigger Codes Value Set for Electronic Case Reporting. (incorporated by reference, see § 170.299).
                            </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>4. Amend § 170.207 by:</AMDPAR>
                        <AMDPAR>a. Adding paragraph (a)(1);</AMDPAR>
                        <AMDPAR>
                            b. Removing and reserving paragraph (a)(3);
                            <PRTPAGE P="1427"/>
                        </AMDPAR>
                        <AMDPAR>c. Adding paragraph (c)(1);</AMDPAR>
                        <AMDPAR>d. Removing and reserving paragraph (c)(2);</AMDPAR>
                        <AMDPAR>e. Adding paragraphs (d)(1) and (4);</AMDPAR>
                        <AMDPAR>f. Adding paragraphs (e)(1) and (2), (f)(3)and (m)(2);</AMDPAR>
                        <AMDPAR>g. Revising paragraph (n)(1);</AMDPAR>
                        <AMDPAR>h. Adding paragraphs (n)(2) and (3);</AMDPAR>
                        <AMDPAR>i. Revising paragraphs (o)and (p); and</AMDPAR>
                        <AMDPAR>j. Adding paragraphs (r)(2) and (s)(2).</AMDPAR>
                        <P>The additions and revisions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.207</SECTNO>
                            <SUBJECT> Vocabulary standards for representing electronic health information.</SUBJECT>
                            <P>(a) * * *</P>
                            <P>
                                (1) 
                                <E T="03">Standard.</E>
                                 SNOMED CT®, U.S. Edition, March 2022 Release (incorporated by reference, see § 170.299).
                            </P>
                            <STARS/>
                            <P>(c) * * *</P>
                            <P>
                                (1) 
                                <E T="03">Standard.</E>
                                 Logical Observation Identifiers Names and Codes (LOINC®) Database Version 2.72, a universal code system for identifying health measurements, observations, and documents produced by the Regenstrief Institute, Inc., February 16, 2022 (incorporated by reference, see § 170.299).
                            </P>
                            <STARS/>
                            <P>(d) * * *</P>
                            <P>
                                (1) 
                                <E T="03">Standard.</E>
                                 RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, July 5, 2022 (incorporated by reference, see § 170.299).
                            </P>
                            <STARS/>
                            <P>
                                (4) 
                                <E T="03">Standard.</E>
                                 The code set specified at 45 CFR 162.1002(b)(2) as referenced in 45 CFR 162.1002(c)(1) for the time period on or after October 1, 2015.
                            </P>
                            <P>(e) * * *</P>
                            <P>
                                (1) 
                                <E T="03">Standard.</E>
                                 HL7® Standard Code Set CVX—Vaccines Administered, dated through June 15, 2022 (incorporated by reference, see § 170.299).
                            </P>
                            <P>
                                (2) 
                                <E T="03">Standard.</E>
                                 National Drug Code Directory (NDC)—Vaccine NDC Linker, dated July 19, 2022 (incorporated by reference, see § 170.299).
                            </P>
                            <STARS/>
                            <P>(f) * * *</P>
                            <P>
                                (3) 
                                <E T="03">Standard.</E>
                                 CDC Race and Ethnicity Code Set Version 1.2 (July 08, 2021) (incorporated by reference, see § 170.299).
                            </P>
                            <STARS/>
                            <P>(m) * * *</P>
                            <P>
                                (2) 
                                <E T="03">Standard.</E>
                                 The Unified Code for Units of Measure, Version 2.1, November 21, 2017 (incorporated by reference, see § 170.299).
                            </P>
                            <P>(n) * * *</P>
                            <P>
                                (1) 
                                <E T="03">Standard.</E>
                                 Birth sex must be coded in accordance with HL7® Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor (incorporated by reference, see § 170.299), up until the adoption of this standard expires January 1, 2026, attributed as follows:
                            </P>
                            <P>(i) Male. M;</P>
                            <P>(ii) Female. F;</P>
                            <P>(iii) Unknown. NullFlavor UNK.</P>
                            <P>
                                (2) 
                                <E T="03">Standard.</E>
                                 Sex must be coded in accordance with, at a minimum, the version of SNOMED CT ® U.S. Edition codes specified in paragraph (a)(1) of this section.
                            </P>
                            <P>
                                (3) 
                                <E T="03">Standard.</E>
                                 Sex Parameter for Clinical Use must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(1) of this section.
                            </P>
                            <P>
                                (o) 
                                <E T="03">Sexual orientation and gender information</E>
                                —(1) 
                                <E T="03">Standard.</E>
                                 Sexual orientation must be coded in accordance with, at a minimum, the version of SNOMED-CT® U.S. Edition codes specified in paragraph (a)(4) of this section for paragraphs (o)(1)(i) through (iii) of this section and HL7 Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor (incorporated by reference, see § 170.299), up until the adoption of this standard expires on January 1, 2026, for paragraphs (o)(1)(iv) through (vi) of this section, attributed as follows:
                            </P>
                            <P>
                                (i) 
                                <E T="03">Lesbian, gay or homosexual.</E>
                                 38628009
                            </P>
                            <P>
                                (ii) 
                                <E T="03">Straight or heterosexual.</E>
                                 20430005
                            </P>
                            <P>
                                (iii) 
                                <E T="03">Bisexual.</E>
                                 42035005
                            </P>
                            <P>
                                (iv) 
                                <E T="03">Something else, please describe.</E>
                                 NullFlavor OTH
                            </P>
                            <P>
                                (v) 
                                <E T="03">Don't know.</E>
                                 NullFlavor UNK
                            </P>
                            <P>
                                (vi) 
                                <E T="03">Choose not to disclose.</E>
                                 NullFlavor ASKU
                            </P>
                            <P>
                                (2) 
                                <E T="03">Standard.</E>
                                 Gender identity must be coded in accordance with, at a minimum, the version of SNOMED-CT® codes specified in paragraph (a)(4) of this section for paragraphs (o)(2)(i) through (v) of this section and HL7® Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor (incorporated by reference in § 170.299), up until the adoption of this standard expires January 1, 2026, for paragraphs (o)(2)(vi) and (vii) of this section, attributed as follows:
                            </P>
                            <P>
                                (i) 
                                <E T="03">Male.</E>
                                 446151000124109
                            </P>
                            <P>
                                (ii) 
                                <E T="03">Female.</E>
                                 446141000124107
                            </P>
                            <P>
                                (iii) 
                                <E T="03">Female-to-Male (FTM)/Transgender Male/Trans Man.</E>
                                 407377005
                            </P>
                            <P>
                                (iv) 
                                <E T="03">Male-to-Female (MTF)/Transgender Female/Trans Woman.</E>
                                 407376001
                            </P>
                            <P>
                                (v) 
                                <E T="03">Genderqueer, neither exclusively male nor female.</E>
                                 446131000124102
                            </P>
                            <P>
                                (vi) 
                                <E T="03">Additional gender category or other, please specify.</E>
                                 NullFlavor OTH
                            </P>
                            <P>
                                (vii) 
                                <E T="03">Choose not to disclose.</E>
                                 NullFlavor ASKU
                            </P>
                            <P>
                                (3) 
                                <E T="03">Standard.</E>
                                 Sexual Orientation and Gender Identity must be coded in accordance with, at a minimum, the version of SNOMED CT® codes specified in paragraph (a)(1) of this section.
                            </P>
                            <P>
                                (4) 
                                <E T="03">Standard.</E>
                                 Pronouns must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(1) of this section.
                            </P>
                            <P>
                                (p) 
                                <E T="03">Social, psychological, and behavioral data</E>
                                —(1) 
                                <E T="03">Financial resource strain.</E>
                                 Financial resource strain must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(1) of this section and attributed with the LOINC® code 76513-1 and LOINC® answer list ID LL3266-5.
                            </P>
                            <P>
                                (2) 
                                <E T="03">Education.</E>
                                 Education must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(1) of this section and attributed with LOINC® code 63504-5 and LOINC® answer list ID LL1069-5.
                            </P>
                            <P>
                                (3) 
                                <E T="03">Stress.</E>
                                 Stress must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(1) of this section and attributed with the LOINC® code 76542-0 and LOINC® answer list LL3267-3.
                            </P>
                            <P>
                                (4) 
                                <E T="03">Depression.</E>
                                 Depression must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(1) of this section and attributed with LOINC® codes 55757-9, 44250-9 (with LOINC® answer list ID LL361-7), 44255-8 (with LOINC® answer list ID LL361-7), and 55758-7 (with the answer coded with the associated applicable unit of measure in the standard specified in paragraph (m)(2) of this section).
                            </P>
                            <P>
                                (5) 
                                <E T="03">Physical activity.</E>
                                 Physical activity must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(1) of this section and attributed with LOINC® codes 68515-6 and 68516-4. The answers must be coded with the associated applicable unit of measure in the standard specified in paragraph (m)(2) of this section.
                            </P>
                            <P>
                                (6) 
                                <E T="03">Alcohol use.</E>
                                 Alcohol use must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(1) of this section and attributed with LOINC® codes 72109-2, 68518-0 (with LOINC® answer list ID LL2179-1), 68519-8 (with LOINC® answer list ID LL2180-9), 68520-6 (with LOINC® answer list ID LL2181-7), and 75626-2 (with the answer coded with the associated applicable unit of measure in the standard specified in paragraph (m)(2) of this section).
                                <PRTPAGE P="1428"/>
                            </P>
                            <P>
                                (7) 
                                <E T="03">Social connection and isolation.</E>
                                 Social connection and isolation must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(1) of this section and attributed with the LOINC® codes 76506-5, 63503-7 (with LOINC® answer list ID LL1068-7), 76508-1 (with the associated applicable unit of measure in the standard specified in paragraph (m)(2) of this section), 76509-9 (with the associated applicable unit of measure in the standard specified in paragraph (m)(2) of this section), 76510-7 (with the associated applicable unit of measure in the standard specified in paragraph (m)(2) of this section), 76511-5 (with LOINC answer list ID LL963-0), and 76512-3 (with the associated applicable unit of measure in the standard specified in paragraph (m)(2) of this section).
                            </P>
                            <P>
                                (8) 
                                <E T="03">Exposure to violence (intimate partner violence).</E>
                                 Exposure to violence: Intimate partner violence must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(1) of this section and attributed with the LOINC® code 76499-3, 76500-8 (with LOINC® answer list ID LL963-0), 76501-6 (with LOINC® answer list ID LL963-0), 76502-4 (with LOINC® answer list ID LL963-0), 76503-2 (with LOINC® answer list ID LL963-0), and 76504-0 (with the associated applicable unit of measure in the standard specified in paragraph (m)(2) of this section).
                            </P>
                            <STARS/>
                            <P>(r) * * *</P>
                            <P>
                                (2) 
                                <E T="03">Standard.</E>
                                 Medicare Provider and Supplier Taxonomy Crosswalk, 2021 (incorporated by reference, see § 170.299).
                            </P>
                            <P>(s) * * *</P>
                            <P>
                                (2) 
                                <E T="03">Standard.</E>
                                 Public Health Data Standards Consortium Users Guide for Source of Payment Typology, Version 9.2 (incorporated by reference, see § 170.299).
                            </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>5. Amend § 170.210 by revising paragraph (g) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 170.210 </SECTNO>
                            <SUBJECT>Standards for health information technology to protect electronic health information created, maintained, and exchanged.</SUBJECT>
                            <STARS/>
                            <P>
                                (g) 
                                <E T="03">Synchronized clocks.</E>
                                 The date and time recorded utilize a system clock that has been synchronized using any Network Time Protocol (NTP) standard.
                            </P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>6. Revise § 170.213 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 170.213</SECTNO>
                            <SUBJECT> United States Core Data for Interoperability.</SUBJECT>
                            <P>The Secretary adopts the following versions of the United States Core Data for Interoperability standard:</P>
                            <P>
                                (a) 
                                <E T="03">Standard.</E>
                                 United States Core Data for Interoperability (USCDI), July 2020 Errata, Version 1 (v1) (incorporated by reference, see § 170.299). The adoption of this standard expires on January 1, 2026.
                            </P>
                            <P>
                                (b) 
                                <E T="03">Standard.</E>
                                 United States Core Data for Interoperability Version 3 (USCDI v3) (incorporated by reference, see § 170.299).
                            </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>7. Revise § 170.215 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 170.215</SECTNO>
                            <SUBJECT> Application Programming Interface Standards.</SUBJECT>
                            <P>The Secretary adopts the following standards and associated implementation specifications as the available standards for application programming interfaces (API):</P>
                            <P>
                                (a) 
                                <E T="03">API base standard.</E>
                                 The following are applicable for purposes of standards-based APIs.
                            </P>
                            <P>
                                (1) 
                                <E T="03">Standard.</E>
                                 HL7® Fast Healthcare Interoperability Resources (FHIR®) Release 4.0.1 (incorporated by reference, see § 170.299).
                            </P>
                            <P>(2) [Reserved]</P>
                            <P>
                                (b) 
                                <E T="03">API constraints and profiles.</E>
                                 The following are applicable for purposes of constraining and profiling data standards.
                            </P>
                            <P>
                                (1) 
                                <E T="03">United States Core Data Implementation Guides—</E>
                                (i) 
                                <E T="03">Implementation specification.</E>
                                 HL7® FHIR® US Core Implementation Guide STU 3.1.1 (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2026.
                            </P>
                            <P>
                                (ii) 
                                <E T="03">Implementation Specification.</E>
                                 HL7® FHIR® US Core Implementation Guide STU 6.1.0 (incorporated by reference, see § 170.299).
                            </P>
                            <P>(2) [Reserved]</P>
                            <P>
                                (c) 
                                <E T="03">Application access and launch.</E>
                                 The following are applicable for purposes of enabling client applications to access and integrate with data systems.
                            </P>
                            <P>
                                (1) 
                                <E T="03">Implementation specification.</E>
                                 HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0, including mandatory support for the “SMART Core Capabilities” (incorporated by reference, see § 170.299). The adoption of this standard expires on January 1, 2026.
                            </P>
                            <P>
                                (2) 
                                <E T="03">Implementation specification.</E>
                                 HL7® SMART App Launch Implementation Guide Release 2.0.0, including mandatory support for the “Capability Sets” of “Patient Access for Standalone Apps” and “Clinician Access for EHR Launch”; all “Capabilities” as defined in “8.1.2 Capabilities,” excepting the “permission-online” capability; “Token Introspection” as defined in “7 Token Introspection” (incorporated by reference, see § 170.299).
                            </P>
                            <P>
                                (d) 
                                <E T="03">Bulk export and data transfer standards.</E>
                                 The following are applicable for purposes of enabling access to large volumes of information on a group of individuals.
                            </P>
                            <P>
                                (1) 
                                <E T="03">Implementation specification.</E>
                                 FHIR® Bulk Data Access (Flat FHIR®) (v1.0.0: STU 1), including mandatory support for the “group-export” “OperationDefinition” (incorporated by reference, see § 170.299).
                            </P>
                            <P>(2) [Reserved]</P>
                            <P>
                                (e) 
                                <E T="03">API authentication, security, and privacy.</E>
                                 The following are applicable for purposes of authorizing and authenticating client applications.
                            </P>
                            <P>
                                (1) 
                                <E T="03">Standard.</E>
                                 OpenID Connect Core 1.0, incorporating errata set 1 (incorporated by reference, see § 170.299).
                            </P>
                            <P>(2) [Reserved]</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>8. Amend § 170.299 by:</AMDPAR>
                        <AMDPAR>a. Revising paragraph (a) and the introductory text of paragraph (d);</AMDPAR>
                        <AMDPAR>b. Adding paragraphs (d)(17) through (19);</AMDPAR>
                        <AMDPAR>c. Revising the introductory text of paragraph (e) and adding paragraph (e)(6)</AMDPAR>
                        <AMDPAR>d. Removing paragraph (j) and redesignating paragraphs (f) through (i) as paragraphs (g) through (j), respectively;</AMDPAR>
                        <AMDPAR>e. Adding new paragraph (f);</AMDPAR>
                        <AMDPAR>f. Revising the introductory text of newly redesignated paragraph (g) and adding paragraphs (g)(35) through (40);</AMDPAR>
                        <AMDPAR>g. Revising the introductory text of paragraph (m) and adding paragraph (m)(6);</AMDPAR>
                        <AMDPAR>h. Revising the introductory text of paragraph (o) and adding paragraph (o)(2);</AMDPAR>
                        <AMDPAR>i. Revising the introductory text of paragraph (p) and adding paragraphs (p)(5) and (6);</AMDPAR>
                        <AMDPAR>j. Revising the introductory text of paragraph (r) and adding paragraphs (r)(8) and (9).</AMDPAR>
                        <P>The revisions and additions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.299 </SECTNO>
                            <SUBJECT>Incorporation by reference.</SUBJECT>
                            <P>
                                (a) Certain material is incorporated by reference into this part with the approval of the Director of the Federal Register under 5 U.S.C. 552(b) and 1 CFR part 51. All approved incorporation by reference (IBR) material is available for inspection at the U.S. Department of Health and Human Services (HHS) and at the National Archives and Records Administration (NARA). Contact HHS at: U.S. Department of Health and 
                                <PRTPAGE P="1429"/>
                                Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW, Washington, DC 20201; call ahead to arrange for inspection at 202-690-7151. For information on the availability of this material at NARA, visit 
                                <E T="03">www.archives.gov/federal-register/cfr/ibr-locations</E>
                                 or email 
                                <E T="03">fr.inspection@nara.gov.</E>
                                 The material may be obtained from the sources in the following paragraphs of this section.
                            </P>
                            <STARS/>
                            <P>
                                (d) Centers for Disease Control and Prevention, 2500 Century Parkway, Mailstop E-78, Atlanta, GA 30333; phone: (800) 232-4636); website: 
                                <E T="03">www.cdc.gov/cdc-info/index.html</E>
                            </P>
                            <STARS/>
                            <P>(17) HL7® Standard Code Set CVX—Vaccines Administered, dated June 15, 2022; IBR approved for § 170.207(e).</P>
                            <P>(18) National Drug Code Directory (NDC)—Vaccine NDC Linker, dated July 19, 2022; IBR approved for § 170.207(e).</P>
                            <P>(19) CDC Race and Ethnicity Code Set version 1.2 (July 08, 2021); IBR approved for § 170.207(f).</P>
                            <P>
                                (e) Centers for Medicare &amp; Medicaid Services, Office of Clinical Standards and Quality, 7500 Security Boulevard, Baltimore, Maryland 21244; phone: (410) 786-3000; website: 
                                <E T="03">www.cms.gov.</E>
                            </P>
                            <STARS/>
                            <P>(6) Medicare Provider and Supplier Taxonomy Crosswalk, 2021; IBR approved for § 170.207(r).</P>
                            <P>
                                (f) Council of State and Territorial Epidemiologists, 2635 Century Parkway NE, Suite 700, Atlanta, GA 30345; phone: (770) 458-3811; website: 
                                <E T="03">www.cste.org/</E>
                            </P>
                            <P>(1) Reportable Conditions Trigger Codes Value Set for Electronic Case Reporting. RCTC OID: 2.16.840.1.114222.4.11.7508, Release March 29, 2022; IBR approved for § 170.205(t).</P>
                            <P>(2) [Reserved]</P>
                            <P>
                                (g) Health Level Seven, 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 48104; phone: (734) 677-7777; website: 
                                <E T="03">www.hl7.org/</E>
                            </P>
                            <STARS/>
                            <P>(35) HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1 (US Realm) Standard for Trial Use, Specification Version: 4.1.1, June 2023 (including appendices A and B); IBR approved for § 170.205(a).</P>
                            <P>(36) HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR)—US Realm, Version 2.1.0—STU 2 US (HL7 FHIR eCR IG), August 31, 2022; IBR approved for § 170.205(t).</P>
                            <P>(37) HL7 CDA® R2 Implementation Guide: Public Health Case Report—the Electronic Initial Case Report (eICR) Release 2, STU Release 3.1—US Realm (HL7 CDA eICR IG), July 2022, volumes 1 and 2; IBR approved for § 170.205(t).</P>
                            <P>(38) HL7 CDA® R2 Implementation Guide: Reportability Response, Release 1, STU Release 1.1—US Realm (HL7 CDA RR IG), July 2022, volumes 1 through 4; IBR approved for § 170.205(t).</P>
                            <P>(39) HL7 FHIR US Core Implementation Guide Version 6.1.0—STU 6, June 19, 2023; IBR approved for § 170.215(b).</P>
                            <P>(40) HL7 FHIR® SMART App Launch [Implementation Guide], 2.0.0—Standard for Trial Use, November 26, 2021; IBR approved for § 170.215(c).</P>
                            <STARS/>
                            <P>
                                (m) Office of the National Coordinator for Health Information Technology (ONC), 330 C Street SW, Washington, DC 20201; phone: (202) 690-7151; website: 
                                <E T="03">https://healthit.gov.</E>
                            </P>
                            <STARS/>
                            <P>(6) United States Core Data for Interoperability (USCDI), Version 3 (v3), October 2022 Errata; IBR approved for § 170.213(b).</P>
                            <STARS/>
                            <P>
                                (o) Public Health Data Standards Consortium, 111 South Calvert Street, Suite 2700, Baltimore, MD 21202; phone: (801) 532-2299; website: 
                                <E T="03">www.Ph.D.sc.org/.</E>
                            </P>
                            <STARS/>
                            <P>(2) Users Guide for Source of Payment Typology, Version 9.2, December 2020; IBR approved for § 170.207(s).</P>
                            <P>
                                (p) Regenstrief Institute, Inc., LOINC® c/o Regenstrief Center for Biomedical Informatics, Inc., 410 West 10th Street, Suite 2000, Indianapolis, IN 46202-3012; phone: (317) 274-9000; website: 
                                <E T="03">https://loinc.org/</E>
                                 and 
                                <E T="03">https://ucum.org/ucum.</E>
                            </P>
                            <STARS/>
                            <P>(5) Logical Observation Identifiers Names and Codes (LOINC®) Database Version 2.72, February 2022; IBR approved for § 170.207(c).</P>
                            <P>(6) The Unified Code for Units of Measure, Version 2.1, November 21, 2017; IBR approved for § 170.207(m).</P>
                            <STARS/>
                            <P>
                                (r) U.S. National Library of Medicine, 8600 Rockville Pike, Bethesda, MD 20894; phone (301) 594-5983; website: 
                                <E T="03">www.nlm.nih.gov/.</E>
                            </P>
                            <STARS/>
                            <P>(8) SNOMED CT® [Systematized Nomenclature of Medicine Clinical Terms] U.S. Edition, March 2022 Release; IBR approved for § 170.207(a).</P>
                            <P>(9) RxNorm, Full Update Release, July 5, 2022; IBR approved for § 170.207(d).</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>9. Amend § 170.315 by:</AMDPAR>
                        <AMDPAR>
                            a. Revising the section heading, introductory text, and paragraphs (a)(5) paragraph heading, (a)(5)(i) introductory text, (a)(5)(i)(A)(
                            <E T="03">1</E>
                            ) and (
                            <E T="03">2</E>
                            ), (a)(5)(i)(C), (D), and (E);
                        </AMDPAR>
                        <AMDPAR>b. Adding paragraphs (a)(5)(i)(F), (G), and (H) and (a)(9)(vi);</AMDPAR>
                        <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), and (b)(2)(iv), (b)(3), (b)(6)(ii)(B)(
                            <E T="03">2</E>
                            ), (b)(9)(ii);
                        </AMDPAR>
                        <AMDPAR>d. Adding paragraph (b)(11);</AMDPAR>
                        <AMDPAR>e. Revising paragraphs (c)(4)(iii)(C), (E), (G), (H), and (I);</AMDPAR>
                        <AMDPAR>
                            f. Revising paragraphs (e)(1)(i)(A)(
                            <E T="03">1</E>
                            ) and (
                            <E T="03">2</E>
                            ), (e)(1)(i)(B)(
                            <E T="03">1</E>
                            ) and (
                            <E T="03">2</E>
                            ), and adding paragraph (e)(1)(iii);
                        </AMDPAR>
                        <AMDPAR>g. Revising paragraphs (f)(1)(i)(B) and (C), (f)(3)(ii), (f)(4)(ii), (f)(5); and</AMDPAR>
                        <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>
                            )(i), (
                            <E T="03">ii</E>
                            ) and (B), (
                            <E T="03">2</E>
                            )(
                            <E T="03">i</E>
                            ) and (
                            <E T="03">ii</E>
                            ), (g)(10)(vi), and (g)(10)(vii).
                        </AMDPAR>
                        <P>The revisions and additions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.315 </SECTNO>
                            <SUBJECT>ONC Certification Criteria for Health IT.</SUBJECT>
                            <P>The Secretary adopts the following certification criteria for health IT. Health IT must be able to electronically perform the following capabilities in accordance with applicable standards and implementation specifications adopted in this part. For all criteria in this section, a health IT developer with a Health IT Module certified to any revised certification criterion, as defined in § 170.102, shall update the Health IT Module and shall provide such update to their customers in accordance with the dates identified for each revised certification criterion and for each applicable standard in 45 CFR part 170 subpart B.</P>
                            <P>(a) * * *</P>
                            <P>
                                (5) 
                                <E T="03">Patient demographics and observations.</E>
                                 (i) Enable a user to record, change, and access patient demographic and observations data including race, ethnicity, preferred language, sex, sex parameter for clinical use, sexual orientation, gender identity, name to use, pronouns, and date of birth.
                            </P>
                            <P>(A) * * *</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Enable each one of a patient's races to be recorded in accordance with, at a minimum, the standard specified in § 170.207(f)(3) and whether a patient declines to specify race.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Enable each one of a patient's ethnicities to be recorded in accordance with, at a minimum, the standard 
                                <PRTPAGE P="1430"/>
                                specified in § 170.207(f)(3) and whether a patient declines to specify ethnicity.
                            </P>
                            <STARS/>
                            <P>
                                (C) 
                                <E T="03">Sex.</E>
                                 Enable sex to be recorded in accordance with the standard specified in § 170.207(n)(1) for the period up to and including December 31, 2025; or § 170.207(n)(2).
                            </P>
                            <P>
                                (D) 
                                <E T="03">Sexual orientation.</E>
                                 Enable sexual orientation to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(1) for the period up to and including December 31, 2025; or § 170.207(o)(3), as well as whether a patient declines to specify sexual orientation.
                            </P>
                            <P>
                                (E) 
                                <E T="03">Gender identity.</E>
                                 Enable gender identity to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(2) for the period up to and including December 31, 2025; or § 170.207(o)(3), as well as whether a patient declines to specify gender identity.
                            </P>
                            <P>
                                (F) 
                                <E T="03">Sex Parameter for Clinical Use.</E>
                                 Enable at least one sex parameter for clinical use to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(3). Conformance with this paragraph is required by January 1, 2026.
                            </P>
                            <P>
                                (G) 
                                <E T="03">Name to Use.</E>
                                 Enable at least one preferred name to use to be recorded. Conformance with this paragraph is required by January 1, 2026.
                            </P>
                            <P>
                                (H) 
                                <E T="03">Pronouns.</E>
                                 Enable at least one pronoun to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(4). Conformance with this paragraph is required by January 1, 2026.
                            </P>
                            <STARS/>
                            <P>(9) * * *</P>
                            <P>
                                (vi) 
                                <E T="03">Expiration of Criterion.</E>
                                 The adoption of this criterion for purposes of the ONC Health IT Certification Program expires on January 1, 2025.
                            </P>
                            <STARS/>
                            <P>
                                (12) 
                                <E T="03">Family health history.</E>
                                 Enable a user to record, change, and access a patient's family health history in accordance with the familial concepts or expressions included in, at a minimum, the version of the standard in § 170.207(a)(1).
                            </P>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>(1) * * *</P>
                            <P>(iii) * * *</P>
                            <P>(A) * * *</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) The data classes expressed in the standards in § 170.213 and in accordance with § 170.205(a)(4), (5), and paragraphs (b)(1)(iii)(A)(
                                <E T="03">3</E>
                                )(
                                <E T="03">i</E>
                                ) through (
                                <E T="03">iii</E>
                                ) of this section for the time period up to and including December 31, 2025, or
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The data classes expressed in the standards in § 170.213 and in accordance with § 170.205(a)(4), (6), and paragraphs (b)(1)(iii)(A)(
                                <E T="03">3</E>
                                )(
                                <E T="03">i</E>
                                ) through (
                                <E T="03">iii</E>
                                ) of this section, and
                            </P>
                            <STARS/>
                            <P>(B) * * *</P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) At a minimum, the version of the standard specified in § 170.207(a)(1).
                            </P>
                            <STARS/>
                            <P>
                                (G) 
                                <E T="03">Patient matching data.</E>
                                 First name, last name, previous name, middle name (including middle initial), suffix, date of birth, current address, phone number, and sex. The following constraints apply:
                            </P>
                            <STARS/>
                            <P>
                                (
                                <E T="03">3</E>
                                ) 
                                <E T="03">Sex Constraint:</E>
                                 Represent sex with the standards adopted in § 170.207(n)(2).
                            </P>
                            <P>(2) * * *</P>
                            <P>
                                (i) 
                                <E T="03">General Requirements.</E>
                                 Paragraphs (b)(2)(ii) and (iii) of this section must be completed based on the receipt of a transition of care/referral summary formatted in accordance with the standards adopted in § 170.205(a)(3) through (5) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates, for time period up to and including December 31, 2025; or in accordance with the standards adopted in § 170.205(a)(3), (4), (6).
                            </P>
                            <P>
                                (ii) 
                                <E T="03">Correct patient.</E>
                                 Upon receipt of a transition of care/referral summary formatted according to the standards adopted § 170.205(a)(3) through (5) for the period up to and including December 31, 2025; or according to the standards adopted § 170.205(a)(3), (4), and (6), technology must be able to demonstrate that the transition of care/referral summary received can be properly matched to the correct patient.
                            </P>
                            <P>(iii) * * *</P>
                            <P>(D) Upon a user's confirmation, automatically update the list, and incorporate the following data expressed according to the specified standards:</P>
                            <STARS/>
                            <P>
                                (iv) 
                                <E T="03">System verification.</E>
                                 Based on the data reconciled and incorporated, the technology must be able to create a file formatted according to the standard specified in § 170.205(a)(4) using the Continuity of Care Document template and the standard specified in paragraph (a)(5) of this section for the time period up to and including December 31, 2025; or according to the standard specified in § 170.205(a)(4) using the Continuity of Care Document template and the standard specified in paragraph (a)(6) of this section.
                            </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>
                            <P>(6) * * *</P>
                            <P>(ii) * * *</P>
                            <P>(B) * * *</P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) At a minimum, the version of the standard specified in § 170.207(a)(1).
                            </P>
                            <STARS/>
                            <P>(9) * * *</P>
                            <P>(ii) The standard in § 170.205(a)(5) for the time period up to and including December 31, 2025; or § 170.205(a)(6).</P>
                            <STARS/>
                            <P>(11) Decision support interventions —</P>
                            <P>
                                (i) 
                                <E T="03">Decision support intervention interaction.</E>
                                 Interventions provided to a user must occur when a user is interacting with technology.
                            </P>
                            <P>
                                (ii) 
                                <E T="03">Decision support configuration.</E>
                                 (A) Enable interventions specified in paragraphs (b)(11)(iii) of this section to be configured by a limited set of identified users based on a user's role.
                            </P>
                            <P>(B) Enable interventions when a patient's medications, allergies and intolerance, and problems are incorporated from a transition of care or referral summary received and pursuant to paragraph (b)(2)(iii)(D) of this section.</P>
                            <P>(C) Enable a user to provide electronic feedback data for evidence-based decision support interventions selected via the capability provided in paragraph (b)(11)(iii)(A) of this section and make available such feedback data to a limited set of identified users for export, in a computable format, including at a minimum the intervention, action taken, user feedback provided (if applicable), user, date, and location.</P>
                            <P>
                                (iii) 
                                <E T="03">Decision support intervention selection.</E>
                                 Enable a limited set of identified users to select (
                                <E T="03">i.e.,</E>
                                 activate) electronic decision support interventions (in addition to drug-drug and drug-allergy contraindication checking) that are:
                            </P>
                            <P>(A) Evidence-based decision support interventions and use any data based on the following data expressed in the standards in § 170.213:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Problems;
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Medications;
                            </P>
                            <P>
                                (
                                <E T="03">3</E>
                                ) Allergies and Intolerances;
                            </P>
                            <P>
                                (
                                <E T="03">4</E>
                                ) At least one demographic specified in paragraph (a)(5)(i) of this section;
                            </P>
                            <P>
                                (
                                <E T="03">5</E>
                                ) Laboratory;
                            </P>
                            <P>
                                (
                                <E T="03">6</E>
                                ) Vital Signs;
                            </P>
                            <P>
                                (
                                <E T="03">7</E>
                                ) Unique Device Identifier(s) for a Patient's Implantable Device(s); and
                            </P>
                            <P>
                                (
                                <E T="03">8</E>
                                ) Procedures.
                            </P>
                            <P>
                                (B) Predictive Decision Support Interventions and use any data expressed in the standards in § 170.213.
                                <PRTPAGE P="1431"/>
                            </P>
                            <P>
                                (iv) 
                                <E T="03">Source attributes.</E>
                                 Source attributes listed in paragraphs (b)(11)(iv)(A) and (B) of this section must be supported.
                            </P>
                            <P>(A) For evidence-based decision support interventions:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Bibliographic citation of the intervention (clinical research or guideline);
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Developer of the intervention (translation from clinical research or guideline);
                            </P>
                            <P>
                                (
                                <E T="03">3</E>
                                ) Funding source of the technical implementation for the intervention(s) development;
                            </P>
                            <P>
                                (
                                <E T="03">4</E>
                                ) Release and, if applicable, revision dates of the intervention or reference source;
                            </P>
                            <P>
                                (
                                <E T="03">5</E>
                                ) Use of race as expressed in the standards in § 170.213;
                            </P>
                            <P>
                                (
                                <E T="03">6</E>
                                ) Use of ethnicity as expressed in the standards in § 170.213;
                            </P>
                            <P>
                                (
                                <E T="03">7</E>
                                ) Use of language as expressed in the standards in § 170.213;
                            </P>
                            <P>
                                (
                                <E T="03">8</E>
                                ) Use of sexual orientation as expressed in the standards in § 170.213;
                            </P>
                            <P>
                                (
                                <E T="03">9</E>
                                ) Use of gender identity as expressed in the standards in § 170.213;
                            </P>
                            <P>
                                (
                                <E T="03">10</E>
                                ) Use of sex as expressed in the standards in § 170.213;
                            </P>
                            <P>
                                (
                                <E T="03">11</E>
                                ) Use of date of birth as expressed in the standards in § 170.213;
                            </P>
                            <P>
                                (
                                <E T="03">12</E>
                                ) Use of social determinants of health data as expressed in the standards in § 170.213; and
                            </P>
                            <P>
                                (
                                <E T="03">13</E>
                                ) Use of health status assessments data as expressed in the standards in § 170.213.
                            </P>
                            <P>(B) For Predictive Decision Support Interventions:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Details and output of the intervention, including:
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) Name and contact information for the intervention developer;
                            </P>
                            <P>
                                (
                                <E T="03">ii</E>
                                ) Funding source of the technical implementation for the intervention(s) development;
                            </P>
                            <P>
                                (
                                <E T="03">iii</E>
                                ) Description of value that the intervention produces as an output; and
                            </P>
                            <P>
                                (
                                <E T="03">iv</E>
                                ) Whether the intervention output is a prediction, classification, recommendation, evaluation, analysis, or other type of output.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Purpose of the intervention, including:
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) Intended use of the intervention;
                            </P>
                            <P>
                                (
                                <E T="03">ii</E>
                                ) Intended patient population(s) for the intervention's use;
                            </P>
                            <P>
                                (
                                <E T="03">iii</E>
                                ) Intended user(s); and
                            </P>
                            <P>
                                (
                                <E T="03">iv</E>
                                ) Intended decision-making role for which the intervention was designed to be used/for (
                                <E T="03">e.g.,</E>
                                 informs, augments, replaces clinical management).
                            </P>
                            <P>
                                (
                                <E T="03">3</E>
                                ) Cautioned out-of-scope use of the intervention, including:
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) Description of tasks, situations, or populations where a user is cautioned against applying the intervention; and
                            </P>
                            <P>
                                (
                                <E T="03">ii</E>
                                ) Known risks, inappropriate settings, inappropriate uses, or known limitations.
                            </P>
                            <P>
                                (
                                <E T="03">4</E>
                                ) Intervention development details and input features, including at a minimum:
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) Exclusion and inclusion criteria that influenced the training data set;
                            </P>
                            <P>
                                (
                                <E T="03">ii</E>
                                ) Use of variables in paragraphs (b)(11)(iv)(A)(
                                <E T="03">5</E>
                                ) through (
                                <E T="03">13</E>
                                ) of this section as input features;
                            </P>
                            <P>
                                (
                                <E T="03">iii</E>
                                ) Description of demographic representativeness according to variables in paragraphs (b)(11)(iv)(A)(
                                <E T="03">5</E>
                                ) through (
                                <E T="03">13</E>
                                ) of this section including, at a minimum, those used as input features in the intervention;
                            </P>
                            <P>
                                (
                                <E T="03">iv</E>
                                ) Description of relevance of training data to intended deployed setting; and
                            </P>
                            <P>
                                (
                                <E T="03">5</E>
                                ) Process used to ensure fairness in development of the intervention, including:
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) Description of the approach the intervention developer has taken to ensure that the intervention's output is fair; and
                            </P>
                            <P>
                                (
                                <E T="03">ii</E>
                                ) Description of approaches to manage, reduce, or eliminate bias.
                            </P>
                            <P>
                                (
                                <E T="03">6</E>
                                ) External validation process, including:
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) Description of the data source, clinical setting, or environment where an intervention's validity and fairness has been assessed, other than the source of training and testing data
                            </P>
                            <P>
                                (
                                <E T="03">ii</E>
                                ) Party that conducted the external testing;
                            </P>
                            <P>
                                (
                                <E T="03">iii</E>
                                ) Description of demographic representativeness of external data according to variables in paragraph (b)(11)(iv)(A)(
                                <E T="03">5</E>
                                )-(
                                <E T="03">13</E>
                                ) including, at a minimum, those used as input features in the intervention; and
                            </P>
                            <P>
                                (
                                <E T="03">iv</E>
                                ) Description of external validation process.
                            </P>
                            <P>
                                (
                                <E T="03">7</E>
                                ) Quantitative measures of performance, including:
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) Validity of intervention in test data derived from the same source as the initial training data;
                            </P>
                            <P>
                                (
                                <E T="03">ii</E>
                                ) Fairness of intervention in test data derived from the same source as the initial training data;
                            </P>
                            <P>
                                (
                                <E T="03">iii</E>
                                ) Validity of intervention in data external to or from a different source than the initial training data;
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                v) Fairness of intervention in data external to or from a different source than the initial training data;
                            </P>
                            <P>
                                (
                                <E T="03">v</E>
                                ) References to evaluation of use of the intervention on outcomes, including, bibliographic citations or hyperlinks to evaluations of how well the intervention reduced morbidity, mortality, length of stay, or other outcomes;
                            </P>
                            <P>
                                (
                                <E T="03">8</E>
                                ) Ongoing maintenance of intervention implementation and use, including:
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) Description of process and frequency by which the intervention's validity is monitored over time;
                            </P>
                            <P>
                                (
                                <E T="03">ii</E>
                                ) Validity of intervention in local data;
                            </P>
                            <P>
                                (
                                <E T="03">iii</E>
                                ) Description of the process and frequency by which the intervention's fairness is monitored over time;
                            </P>
                            <P>
                                (
                                <E T="03">iv</E>
                                ) Fairness of intervention in local data; and
                            </P>
                            <P>
                                (
                                <E T="03">9</E>
                                ) Update and continued validation or fairness assessment schedule, including:
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) Description of process and frequency by which the intervention is updated; and
                            </P>
                            <P>
                                (
                                <E T="03">ii</E>
                                ) Description of frequency by which the intervention's performance is corrected when risks related to validity and fairness are identified.
                            </P>
                            <P>
                                (v) 
                                <E T="03">Source attribute access and modification.</E>
                                 (A) 
                                <E T="03">Access.</E>
                                 (
                                <E T="03">1</E>
                                ) For evidence-based decision support interventions and Predictive Decision Support Interventions supplied by the health IT developer as part of its Health IT Module, the Health IT Module must enable a limited set of identified users to access complete and up-to-date plain language descriptions of source attribute information specified in paragraphs (b)(11)(iv)(A) and (B) of this section.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) For Predictive Decision Support Interventions supplied by the health IT developer as part of its Health IT Module, the Health IT Module must indicate when information is not available for review for source attributes in paragraphs (b)(11)(iv)(B)(
                                <E T="03">6</E>
                                ); (b)(11)(iv)(B)(
                                <E T="03">7</E>
                                )(
                                <E T="03">iii</E>
                                ), (
                                <E T="03">iv</E>
                                ), and (
                                <E T="03">v</E>
                                ); (b)(11)(iv)(B)(
                                <E T="03">8</E>
                                )(
                                <E T="03">ii</E>
                                ) and (
                                <E T="03">iv</E>
                                ); and (b)(11)(iv)(B)(
                                <E T="03">9</E>
                                ) of this section.
                            </P>
                            <P>
                                (B) 
                                <E T="03">Modify.</E>
                                 (
                                <E T="03">1</E>
                                ) For evidence-based decision support interventions and Predictive Decision Support Interventions, the Health IT Module must enable a limited set of identified users to record, change, and access source attributes in paragraphs (b)(11)(iv)(A) and (B) of this section.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) For Predictive Decision Support Interventions, the Health IT Module must enable a limited set of identified users to record, change, and access additional source attributes not specified in paragraph (b)(11)(iv)(B) of this section.
                            </P>
                            <P>
                                (vi) 
                                <E T="03">Intervention risk management.</E>
                                 Intervention risk management practices must be applied for each Predictive Decision Support Intervention supplied by the health IT developer as part of its Health IT Module.
                            </P>
                            <P>
                                (A) 
                                <E T="03">Risk analysis.</E>
                                 The Predictive Decision Support Intervention(s) must be subject to analysis of potential risks and adverse impacts associated with the following characteristics: validity, reliability, robustness, fairness, 
                                <PRTPAGE P="1432"/>
                                intelligibility, safety, security, and privacy.
                            </P>
                            <P>
                                (B) 
                                <E T="03">Risk mitigation.</E>
                                 The Predictive Decision Support Intervention (s) must be subject to practices to mitigate risks, identified in accordance with paragraph (b)(11)(vi)(A) of this section; and
                            </P>
                            <P>
                                (C) 
                                <E T="03">Governance.</E>
                                 The Predictive Decision Support Intervention(s) must be subject to policies and implemented controls for governance, including how data are acquired, managed, and used.
                            </P>
                            <P>(c) * * *</P>
                            <P>(4) * * *</P>
                            <P>(iii) * * *</P>
                            <P>(C) Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(2).</P>
                            <STARS/>
                            <P>(E) Patient insurance in accordance with the standard specified in § 170.207(s)(2).</P>
                            <STARS/>
                            <P>(G) Patient sex in accordance with the version of the standard specified in § 170.207(n)(2).</P>
                            <P>(H) Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(3).</P>
                            <P>(I) Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(1).</P>
                            <P>(e) * * *</P>
                            <P>(1) * * *</P>
                            <P>(i) * * *</P>
                            <P>(A) * * *</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) The data classes expressed in the standards in § 170.213 (which should be in their English (
                                <E T="03">i.e.,</E>
                                 non-coded) representation if they associate with a vocabulary/code set), and in accordance with § 170.205(a)(4) and (a)(5), and paragraphs (e)(1)(i)(A)(
                                <E T="03">3</E>
                                )(
                                <E T="03">i</E>
                                ) through (
                                <E T="03">iii</E>
                                ) of this section for the time period up to and including December 31, 2025, or
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The data classes expressed in the standards in § 170.213 (which should be in their English (
                                <E T="03">i.e.,</E>
                                 non-coded) representation if they associate with a vocabulary/code set), and in accordance with § 170.205(a)(4) and (a)(6), and paragraphs (e)(1)(i)(A)(
                                <E T="03">3</E>
                                )(
                                <E T="03">i</E>
                                ) through (
                                <E T="03">iii</E>
                                ) of this section.
                            </P>
                            <STARS/>
                            <P>(B) * * *</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Patients (and their authorized representatives) must be able to use technology to download an ambulatory summary or inpatient summary (as applicable to the health IT setting for which certification is requested) in the following formats:
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) Human readable format; and
                            </P>
                            <P>
                                (
                                <E T="03">ii</E>
                                ) The format specified in accordance with the standard specified in § 170.205(a)(4) and (5) for the time period up to and including December 31, 2025, or § 170.205(a)(4) and (6), and following the CCD document template.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) When downloaded according to the standard specified in § 170.205(a)(4) through (6) following the CCD document template, the ambulatory summary or inpatient summary must include, at a minimum, the following data (which, for the human readable version, should be in their English representation if they associate with a vocabulary/code set):
                            </P>
                            <STARS/>
                            <P>
                                (iii) 
                                <E T="03">Request for restrictions.</E>
                                 Patients (and their authorized representatives) must be able to use an internet-based method to request a restriction to be applied for any data expressed in the standards in § 170.213. Conformance with this paragraph is required by January 1, 2026.
                            </P>
                            <STARS/>
                            <P>(f) * * *</P>
                            <P>(1) * * *</P>
                            <P>(i) * * *</P>
                            <P>(B) At a minimum, the version of the standard specified in § 170.207(e)(1) for historical vaccines.</P>
                            <P>(C) At a minimum, the version of the standard specified in § 170.207(e)(2) for administered vaccines.</P>
                            <P>(3) * * *</P>
                            <P>(ii) At a minimum, the versions of the standards specified in § 170.207(a)(1) and (c)(1).</P>
                            <P>(4) * * *</P>
                            <P>(ii) At a minimum, the versions of the standards specified in § 170.207(a)(1) and (c)(1).</P>
                            <P>
                                (5) 
                                <E T="03">Transmission to public health agencies</E>
                                —
                                <E T="03">electronic case reporting.</E>
                                 Enable a user to create a case report for electronic transmission meeting the requirements described in paragraphs (f)(5)(i) of this section for the time period up to and including December 31, 2025; or the requirements described in paragraph (f)(5)(ii) of this section.
                            </P>
                            <P>
                                (i) 
                                <E T="03">Functional electronic case reporting.</E>
                                 A Health IT Module must enable a user to create a case report for electronic transmission in accordance with the following:
                            </P>
                            <P>(A) Consume and maintain a table of trigger codes to determine which encounters may be reportable.</P>
                            <P>(B) Match a patient visit or encounter to the trigger code based on the parameters of the trigger code table.</P>
                            <P>
                                (C) 
                                <E T="03">Case report creation.</E>
                                 Create a case report for electronic transmission:
                            </P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Based on a matched trigger from paragraph (f)(5)(i)(B).
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) That includes, at a minimum:
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) The data classes expressed in the standards in § 170.213.
                            </P>
                            <P>
                                <E T="03">(ii)</E>
                                 Encounter diagnoses formatted according to at least one of the standards specified in § 170.207(i) or § 170.207(a)(1).
                            </P>
                            <P>
                                (
                                <E T="03">iii</E>
                                ) The provider's name, office contact information, and reason for visit.
                            </P>
                            <P>
                                (
                                <E T="03">iv</E>
                                ) An identifier representing the row and version of the trigger table that triggered the case report.
                            </P>
                            <P>
                                (ii) 
                                <E T="03">Standards-based electronic case reporting.</E>
                                 A Health IT Module must enable a user to create a case report for electronic transmission in accordance with the following:
                            </P>
                            <P>(A) Consume and process case reporting trigger codes and identify a reportable patient visit or encounter based on a match from the Reportable Conditions Trigger Code value set in § 170.205(t)(4).</P>
                            <P>(B) Create a case report consistent with at least one of the following standards:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) The eICR profile of the HL7 FHIR eCR IG in § 170.205(t)(1); or
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The HL7 CDA eICR IG in § 170.205(t)(2).
                            </P>
                            <P>(C) Receive, consume, and process a case report response that is formatted to either the reportability response profile of the HL7 FHIR eCR IG in § 170.205(t)(1) or the HL7 CDA RR IG in § 170.205(t)(3) as determined by the standard used in (f)(5)(ii)(B) of this section.</P>
                            <P>(D) Transmit a case report electronically to a system capable of receiving a case report.</P>
                            <STARS/>
                            <P>(g) * * *</P>
                            <P>
                                (3) 
                                <E T="03">Safety-enhanced design.</E>
                                 User-centered design processes must be applied to each capability technology includes that is specified in the following certification criteria: paragraphs (a)(1) through (5), (9) until the criterion's expiration date, and (14), and (b)(2), (3), and (11) of this section.
                            </P>
                            <STARS/>
                            <P>(6) * * *</P>
                            <P>(i) * * *</P>
                            <P>
                                (A) The data classes expressed in the standards in § 170.213 in accordance with § 170.205(a)(4) and (a)(5) and paragraphs (g)(6)(i)(C)(
                                <E T="03">1</E>
                                ) through (
                                <E T="03">4</E>
                                ) of this section for the time period up to and including December 31, 2025; or
                            </P>
                            <P>
                                (B) The data classes expressed in the standards in § 170.213, and in accordance with § 170.205(a)(4) and (6) and paragraphs (g)(6)(i)(C)(
                                <E T="03">1</E>
                                ) through (
                                <E T="03">3</E>
                                ) of this section.
                            </P>
                            <STARS/>
                            <P>(9) * * *</P>
                            <P>(i) * * *</P>
                            <P>(A) * * *</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Respond to requests for patient data (based on an ID or other token) for all of the data classes expressed in the 
                                <PRTPAGE P="1433"/>
                                standards in § 170.213 at one time and return such data (according to the specified standards, where applicable) in a summary record formatted in accordance with § 170.205(a)(4) and (5) following the CCD document template, and as specified in paragraphs (g)(9)(i)(A)(
                                <E T="03">3</E>
                                )(
                                <E T="03">i</E>
                                ) through (
                                <E T="03">iv</E>
                                ) of this section for the time period up to and including December 31, 2025; or
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Respond to requests for patient data (based on an ID or other token) for all of the data classes expressed in the standards in § 170.213 at one time and return such data (according to the specified standards, where applicable) in a summary record formatted in accordance with § 170.205(a)(4) and (6) following the CCD document template, and as specified in paragraphs (g)(9)(i)(A)(
                                <E T="03">3</E>
                                )(
                                <E T="03">i</E>
                                ) through (
                                <E T="03">iv</E>
                                ) of this section.
                            </P>
                            <STARS/>
                            <P>(10) * * *</P>
                            <P>(i) * * *</P>
                            <P>(A) Respond to requests for a single patient's data according to the standards and implementation specifications adopted in 170.215(a) and in § 170.215(b)(1), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standards adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported.</P>
                            <P>(B) Respond to requests for multiple patients' data as a group according to the standards and implementation specifications adopted in § 170.215(a), (b)(1), and (d), for each of the data included in the standards adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported.</P>
                            <P>(ii) * * *</P>
                            <P>(A) Respond to search requests for a single patient's data consistent with the search criteria included in the implementation specifications adopted in § 170.215(b)(1), specifically the mandatory capabilities described in “US Core Server CapabilityStatement.”</P>
                            <P>(B) Respond to search requests for multiple patients' data consistent with the search criteria included in the implementation specification adopted in § 170.215(d).</P>
                            <STARS/>
                            <P>(iv) * * *</P>
                            <P>(A) Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(b)(1) and (c).</P>
                            <P>(B) Establish a secure and trusted connection with an application that requests data for system scopes in accordance with the implementation specification adopted in § 170.215(d).</P>
                            <STARS/>
                            <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>
                                (B) 
                                <E T="03">Authentication and authorization for system scopes.</E>
                                 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>
                            <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>
                            <STARS/>
                            <P>
                                (vi) 
                                <E T="03">Patient authorization revocation.</E>
                                 A Health IT Module's authorization server must be able to revoke and must revoke an authorized application's access at a patient's direction within 1 hour of the request.
                            </P>
                            <P>
                                (vii) 
                                <E T="03">Token introspection.</E>
                                 A Health IT Module's authorization server must be able to receive and validate tokens it has issued in accordance with an implementation specification in § 170.215(c).
                            </P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>10. Amend § 170.402 by adding paragraphs (a)(5), and (b)(3) and (4) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 170.402</SECTNO>
                            <SUBJECT> Assurances.</SUBJECT>
                            <P>(a) * * *</P>
                            <P>(5) A health IT developer must not inhibit its customer's timely access to interoperable health IT certified under the Program.</P>
                            <P>(b) * * *</P>
                            <P>
                                (3)(i) 
                                <E T="03">Update.</E>
                                 A health IT developer must update a Health IT Module, once certified to a certification criterion adopted in § 170.315, to all applicable revised certification criteria, including the most recently adopted capabilities and standards included in the revised certification criterion.
                            </P>
                            <P>
                                (ii) 
                                <E T="03">Provide.</E>
                                 A health IT developer must provide all Health IT Modules certified to a revised certification criterion, including the most recently adopted capabilities and standards included in the revised certification criterion, to its customers of such certified health IT.
                            </P>
                            <P>
                                (iii) 
                                <E T="03">Timeliness.</E>
                                 A health IT developer must complete the actions specified in paragraphs (b)(3)(i) and (ii) of this section:
                            </P>
                            <P>(A) Consistent with the timeframes specified in part 170; or</P>
                            <P>(B) If the developer obtains new customers of health IT certified to the revised criterion after the effective date of the final rule adopting the revised criterion or criteria, then the health IT developer must provide the health IT certified to the revised criterion to such customers within whichever of the following timeframes that expires last:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) The timeframe provided in paragraph (b)(3)(iii)(A) of this section; or
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) No later than 12 months after the purchasing or licensing relationship has been established between the health IT developer and the new customer for the health IT certified to the revised criterion.
                            </P>
                            <P>(4) For developers of Health IT Modules certified to § 170.315(b)(11), starting January 1, 2025, and on an ongoing basis thereafter, review and update as necessary source attribute information in § 170.315(b)(11)(iv)(A) and (B), intervention risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi). </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>11. Amend § 170.404 by revising paragraph (b)(2) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 170.404 </SECTNO>
                            <SUBJECT>Application programming interfaces.</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>
                                (2) 
                                <E T="03">Service base URL publication.</E>
                                 For all Health IT Modules certified to § 170.315(g)(10), a Certified API Developer must publish, at no charge, the service base URLs and related organization details that can be used by patients to access their electronic health 
                                <PRTPAGE P="1434"/>
                                information, by December 31, 2024. This includes all customers regardless of whether the Health IT Modules certified to § 170.315(g)(10) are centrally managed by the Certified API Developer or locally deployed by an API Information Source. These service base URLs and organization details must conform to the following:
                            </P>
                            <P>(i) Service base URLs must be publicly published in Endpoint resource format according to the standard adopted in § 170.215(a).</P>
                            <P>(ii) Organization details for each service base URL must be publicly published in Organization resource format according to the standard adopted in § 170.215(a). Each Organization resource must contain:</P>
                            <P>(A) A reference, in the Organization.endpoint element, to the Endpoint resources containing service base URLs managed by this organization.</P>
                            <P>(B) The organization's name, location, and facility identifier.</P>
                            <P>(iii) Endpoint and Organization resources must be:</P>
                            <P>(A) Collected into a Bundle resource formatted according to the standard adopted in § 170.215(a) for publication; and</P>
                            <P>(B) Reviewed quarterly and, as necessary, updated.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>12. Amend § 170.405 by:</AMDPAR>
                        <AMDPAR>a. Revising paragraphs (a) and (b)(2)(ii); and</AMDPAR>
                        <AMDPAR>b. Removing and reserving paragraphs (b)(3) through (7) and (b)(10).</AMDPAR>
                        <P>The revisions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.405</SECTNO>
                            <SUBJECT> Real world testing.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Condition of Certification requirement.</E>
                                 A health IT developer with one or more Health IT Module(s) certified to any one or more of the ONC Certification Criteria for Health IT in § 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h) must successfully test the real world use of those Health IT Module(s) for interoperability (as defined in 42 U.S.C. 300jj(9) and § 170.102) in the type of setting in which such Health IT Module(s) would be/is marketed.
                            </P>
                            <P>(b) * * *</P>
                            <P>(2) * * *</P>
                            <P>(ii) For real world testing activities conducted during the immediately preceding calendar year, a health IT developer must submit to its ONC-ACB an annual real world testing results report addressing each of its certified Health IT Modules that include certification criteria referenced in paragraph (a) of this section by a date determined by the ONC-ACB that enables the ONC-ACB to publish a publicly available hyperlink to the results report on CHPL no later than March 15 of each calendar year, beginning in 2023. For certified Health IT Modules included in paragraph (a) of this section that are updated using Inherited Certified Status after August 31 of the year in which the plan is submitted, a health IT developer must include the newer version of the certified Health IT Module(s) in its annual real world testing results report. The real world testing results must report the following for each of the certification criteria identified in paragraph (a) of this section that are included in the Health IT Module's scope of certification:</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>13. Add § 170.407 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 170.407 </SECTNO>
                            <SUBJECT>Insights Condition and Maintenance of Certification.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Condition of Certification.</E>
                                 (1) 
                                <E T="03">Measure responses.</E>
                                 A health IT developer must submit (to the independent entity designated by the Secretary) for each reporting period pursuant to paragraph (b) of this section:
                            </P>
                            <P>(i) Responses for the measures specified in this section, which must include:</P>
                            <P>(A) Data aggregated at the product level (across versions);</P>
                            <P>(B) Documentation related to the data sources and methodology used to generate measures; and</P>
                            <P>
                                (C) Percentage of total customers (
                                <E T="03">e.g.,</E>
                                 hospital sites, individual clinician users) represented in provided data; or
                            </P>
                            <P>(ii) A response (attestation) that it does not:</P>
                            <P>(A) Meet the minimum reporting qualifications requirement in paragraph (a)(2) of this section; or</P>
                            <P>(B) Have health IT certified to the certification criteria specified in each measure in paragraphs (a)(3)(i) through (vii) of this section; or</P>
                            <P>(C) Have any users using the certified health IT specified in each measure in paragraphs (a)(3)(i) through (vii) of this section during the reporting period.</P>
                            <P>
                                (2) 
                                <E T="03">Minimum reporting qualifications requirement.</E>
                                 At least 50 hospital sites or 500 individual clinician users across the developer's certified health IT.
                            </P>
                            <P>
                                (3) 
                                <E T="03">Measures.</E>
                                 (i) 
                                <E T="03">Individuals' access to electronic health information through certified health IT.</E>
                                 If a health IT developer has a Health IT Module certified to § 170.315(e)(1) or (g)(10) or both, then the health IT developer must submit responses for the number of unique individuals who access electronic health information (EHI) overall and by different methods of access through certified health IT.
                            </P>
                            <P>
                                (ii) 
                                <E T="03">Consolidated clinical document architecture (C-CDA) problems, medications, and allergies reconciliation and incorporation through certified health IT.</E>
                                 If a health IT developer has a Health IT Module certified to § 170.315(b)(2), then the health IT developer must submit responses for:
                            </P>
                            <P>(A) Encounters;</P>
                            <P>(B) Unique patients with an encounter;</P>
                            <P>(C) C-CDA documents obtained (unique and overall); and</P>
                            <P>(D) C-CDA documents reconciled and incorporated both through manual and automated processes.</P>
                            <P>
                                (iii) 
                                <E T="03">Applications supported through certified health IT.</E>
                                 If a health IT developer has a Health IT Module certified to § 170.315(g)(10), then the health IT developer must submit responses on how their certified health IT is supporting the application ecosystem, by providing the following information for applications that are connected to their certified health IT including:
                            </P>
                            <P>(A) Application Name(s);</P>
                            <P>(B) Application Developer Name(s);</P>
                            <P>(C) Intended Purpose(s) of Application;</P>
                            <P>(D) Intended Application User(s); and</P>
                            <P>(E) Application Status.</P>
                            <P>
                                (iv) 
                                <E T="03">Use of FHIR in apps through certified health IT.</E>
                                 (i) If a health IT developer has a Health IT Module certified to § 170.315(g)(10), then the health IT developer must submit responses on the number of requests made to distinct certified health IT deployments that returned FHIR resources, number of distinct of certified health IT deployments active at any time, the number of distinct deployments active at any time that returned FHIR resources in response to API calls from apps connected to certified health IT, including stratifying responses by the following:
                            </P>
                            <P>(A) User type;</P>
                            <P>(B) FHIR resource; and</P>
                            <P>(C) US Core Implementation Guide version.</P>
                            <P>
                                (v) 
                                <E T="03">Use of FHIR bulk data access through certified health IT.</E>
                                 (i) If a health IT developer has a Health IT Module certified to § 170.315(g)(10), then the health IT developer must submit responses for the total number of FHIR bulk data access requests completed through the certified health IT, and the number of distinct deployments of the certified health IT active at any time overall, and by whether at least one bulk data download request was completed.
                            </P>
                            <P>
                                (vi) 
                                <E T="03">
                                    Immunization administrations electronically submitted to immunization information systems 
                                    <PRTPAGE P="1435"/>
                                    through certified health IT.
                                </E>
                                 (i) If a health IT developer has a Health IT Module certified to § 170.315(f)(1), then the health IT developer must submit responses for the use of certified health IT to electronically send immunizations administered to immunization information systems (IIS), including stratifying responses based on the following subgroups:
                            </P>
                            <P>(A) IIS; and</P>
                            <P>(B) Age group.</P>
                            <P>
                                (vii) 
                                <E T="03">Immunization history and forecasts through certified health IT.</E>
                                 (i) If a health IT developer has a Health IT Module certified to § 170.315(f)(1), then the health IT developer must submit responses for the use of certified health IT to query immunization history and forecast information from immunization information systems (IIS), including stratifying responses based on the following subgroup:
                            </P>
                            <P>(A) IIS.</P>
                            <P>(B) [Reserved]</P>
                            <P>
                                (b) 
                                <E T="03">Maintenance of Certification.</E>
                                 (1) A health IT developer must provide responses to the Insights Condition of Certification specified in paragraph (a) of this section annually for any Health IT Module that has or has had an active certification at any time under the ONC Health IT Certification Program during the prior six months:
                            </P>
                            <P>(i) A health IT developer must provide responses for measures specified in:</P>
                            <P>(A) Paragraphs (a)(3)(i), (iii), (iv)(A) and (B), and (vi) of this section beginning July 2027;</P>
                            <P>(B) Paragraphs (a)(3)(ii)(A) through (C), (iv)(C), (v), (vi)(A) and (B), and (vii) of this section beginning July 2028; and</P>
                            <P>(C) Paragraph (a)(3)(ii)(D), (vii)(A) of this section beginning July 2029.</P>
                            <P>(2) [Reserved]</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>14. Amend § 170.523 by:</AMDPAR>
                        <AMDPAR>a. Revising paragraph (f)(1) introductory text and adding paragraph (f)(1)(xxi);</AMDPAR>
                        <AMDPAR>b. Revising paragraphs (g)(1), (k)(1)(i) and (ii); and</AMDPAR>
                        <AMDPAR>c. Adding paragraph (u).</AMDPAR>
                        <P>The revisions and addition read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.523 </SECTNO>
                            <SUBJECT>Principles of proper conduct for ONC-ACBs.</SUBJECT>
                            <STARS/>
                            <P>(f) * * *</P>
                            <P>(1) For the ONC Certification Criteria for Health IT:</P>
                            <STARS/>
                            <P>(xxi) Where applicable, summary information of the intervention risk management practices listed in § 170.315(b)(11)(vi) is submitted by the health IT developer via publicly accessible hyperlink that allows any person to access the summary information directly without any preconditions or additional steps.</P>
                            <STARS/>
                            <P>(g) * * *</P>
                            <P>(1) Retain all records related to the certification of Health IT Modules to the ONC Certification Criteria for Health IT beginning with the codification of those certification criteria in the Code of Federal Regulations through a minimum of 3 years after the end of calendar year that included the effective date of the removal of those certification criteria from the Code of Federal Regulations; and</P>
                            <STARS/>
                            <P>(k) * * *</P>
                            <P>(1) * * *</P>
                            <P>(i) The disclaimer “This Health IT Module is compliant with the ONC Certification Criteria for Health IT and has been certified by an ONC-ACB in accordance with the applicable certification criteria adopted by the Secretary of Health and Human Services. This certification does not represent an endorsement by the U.S. Department of Health and Human Services.”</P>
                            <P>(ii) For a Health IT Module certified to the ONC Certification Criteria for Health IT, the information specified by paragraphs (f)(1)(i), (vi) through (viii), (xv), and (xvi) of this section as applicable for the specific Health IT Module.</P>
                            <STARS/>
                            <P>
                                (u) 
                                <E T="03">Insights.</E>
                                 Confirm that developers of certified health IT submit responses for Insights Conditions and Maintenance of Certification requirements in accordance with § 170.407.
                            </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>15. Amend § 170.524 by revising paragraph (f)(1) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 170.524 </SECTNO>
                            <SUBJECT>Principles of proper conduct for ONC-ATLs.</SUBJECT>
                            <STARS/>
                            <P>(f) * * *</P>
                            <P>(1) Retain all records related to the testing of Health IT Modules to the ONC Certification Criteria for Health IT beginning with the codification of those certification criteria in the Code of Federal Regulations through a minimum of three years after the end of calendar year that included the effective date of the removal of those certification criteria from the Code of Federal Regulations; and</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>16. Amend § 170.550 by revising paragraphs (g) introductory text 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>
                                (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>
                    <PART>
                        <HD SOURCE="HED">PART 171—INFORMATION BLOCKING</HD>
                    </PART>
                    <REGTEXT TITLE="45" PART="171">
                        <AMDPAR>17. The authority citation for part 171 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P> 42 U.S.C. 300jj-52; 5 U.S.C. 552.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="171">
                        <AMDPAR>18. Amend § 171.102 by</AMDPAR>
                        <AMDPAR>a. Adding, in alphabetical order, the definition of “Business associate”;</AMDPAR>
                        <AMDPAR>b. Revising the definition of “Health IT developer of certified health IT”; and</AMDPAR>
                        <AMDPAR>c. Adding, in alphabetical order, the definition of “Offer health information technology or offer health IT”.</AMDPAR>
                        <P>The additions and revision read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 171.102 </SECTNO>
                            <SUBJECT>Definitions</SUBJECT>
                            <STARS/>
                            <P>
                                <E T="03">Business associate</E>
                                 is defined as it is in 45 CFR 160.103.
                            </P>
                            <STARS/>
                            <P>
                                <E T="03">Health IT developer of certified health IT</E>
                                 means an individual or entity, other than a health care provider that self-develops health IT that is not offered to others, that develops or offers health information technology (as that term is defined in 42 U.S.C. 300jj(5)), and which has, at the time it engages in a practice that is the subject of an information blocking claim, one or more Health IT Modules certified under a program for the voluntary certification of health information technology that is kept or recognized by the National Coordinator pursuant to 42 U.S.C. 300jj-11(c)(5) (ONC Health IT Certification Program).
                            </P>
                            <STARS/>
                            <P>
                                <E T="03">Offer health information technology</E>
                                 or 
                                <E T="03">offer health IT</E>
                                 means to hold out for sale, resale, license, or relicense or to sell, resell, license, relicense, or otherwise provide or supply health information technology (as that term is defined in 42 U.S.C. 300jj(5) and where such health information technology includes one or more Health IT Modules certified under the ONC Health IT Certification Program) for deployment by or for other individual(s) or entity(ies) under any arrangement 
                                <PRTPAGE P="1436"/>
                                except an arrangement consistent with subparagraph (3)(iii), below. Activities and arrangements described in subparagraphs (1) through (3) are considered to be excluded from what it means to offer health IT.
                            </P>
                            <P>(1) Donation and subsidized supply arrangements are not considered offerings when an individual or entity donates, gives, or otherwise makes available funding to subsidize or fully cover the costs of a health care provider's acquisition, augmentation, or upkeep of health IT, provided such individual or entity offers and makes such subsidy without condition(s) limiting the interoperability or use of the technology to access, exchange or use electronic health information for any lawful purpose.</P>
                            <P>(2) Implementation and use activities conducted by an individual or entity as follows:</P>
                            <P>(i) Issuing user accounts or login credentials to the individual's or entity's employees in the course of their employment or contractors within the scope of their contract in order for such employees or contractors to: use, operate, implement, configure, test, maintain, update or upgrade, or to give or receive training on, the individual's or entity's health IT system(s) or specific application(s) within such system(s).</P>
                            <P>(ii) Implementing, operating, or otherwise making available production instances of application programming interface (API) technology that supports access, exchange, and use of electronic health information that the individual or entity has in its possession, custody, control, or ability to query or transmit from or across a health information network or health information exchange.</P>
                            <P>(iii) Implementing, operating, and making available production instances of online portals for patients, clinicians or other health care providers, or public health entities to access, exchange, and use electronic health information that the individual or entity has in its possession, custody, control, or ability to query or transmit from or across a health information network or health information exchange.</P>
                            <P>(iv) Issuing login credentials or user accounts for the individual's or entity's production, development, or testing environments to public health authorities, or such authorities' employees or contractors, as a means of accomplishing or facilitating access, exchange, and use of electronic health information for public health purposes including but not limited to syndromic surveillance.</P>
                            <P>(v) Issuing login credentials or user accounts for independent healthcare professionals who furnish services in a healthcare facility to use the facility's electronic health record or other health IT system(s) in: furnishing, documenting, and accurately billing for care furnished in the facility; participating in clinical education or improvement activities conducted by or in the healthcare facility; or receiving training in use of the healthcare facility's health IT system(s).</P>
                            <P>(3) Consulting and legal services arrangements as follows:</P>
                            <P>(i) Legal services furnished by outside counsel—when furnishing legal services to a client in any matter or matters pertaining to the client's seeking, assessing, selecting, or resolving disputes over contracts or other arrangements by which the client obtains use of certified health IT. Outside counsel also does not offer health IT when facilitating limited access or use of a client's health IT by independent expert witnesses engaged by the outside counsel, opposing parties' counsel and experts, and special masters and court personnel, as appropriate to legal discovery.</P>
                            <P>(ii) Health IT consultant assistance with selection, implementation, and use of health IT —furnished to a health IT customer or user to help the customer do (or to do on behalf of a customer) any or all of the following with respect to any health IT product that the consultant does not sell or resell, license or relicense, or otherwise supply to the customer under any arrangement on a commercial basis or otherwise:</P>
                            <P>(A) Define the business needs of the customer or user or evaluate health IT product(s) against such business needs, or both;</P>
                            <P>(B) Negotiate for the purchase, lease, license, or other arrangement under which the health IT product(s) will be used; or</P>
                            <P>(C) Oversee or carry out configuration, implementation, or operation of health IT product(s).</P>
                            <P>(iii) Comprehensive and predominantly non-health IT administrative or operations management services—when an individual or entity furnishes a health care provider with administrative or operational management consultant services and the consultant acts as the agent of the provider or otherwise acts on behalf of the provider in dealings with one or more health IT developer(s) or vendor(s), or managing the day-to-day operations and administrative duties for the health IT, or both. To be consistent with this subparagraph, such services must be furnished as part of a comprehensive array of predominantly non-health IT administrative and operational functions that would otherwise be executed by the health care provider.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="171">
                        <AMDPAR>19. Revise § 171.103 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 171.103</SECTNO>
                            <SUBJECT> Information blocking.</SUBJECT>
                            <P>(a) Information blocking means a practice that except as required by law or covered by an exception set forth in subparts B, C, or D of this part, is likely to interfere with access, exchange, or use of electronic health information; and</P>
                            <P>(b) If conducted by:</P>
                            <P>(1) A health IT developer of certified health IT, health information network or health information exchange, such developer, network or exchange knows, or should know, that such practice is likely to interfere with access, exchange, or use of electronic health information; or</P>
                            <P>(2) A health care provider, such provider knows that such practice is unreasonable and is likely to interfere with access, exchange, or use of electronic health information. </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="171">
                        <AMDPAR>20. Amend § 171.204 by revising paragraphs (a)(1) and (3) and adding paragraphs (a)(4) and (5) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 171.204 </SECTNO>
                            <SUBJECT>Infeasibility exception—When will an actor's practice of not fulfilling a request to access, exchange, or use electronic health information due to the infeasibility of the request not be considered information blocking?</SUBJECT>
                            <STARS/>
                            <P>(a) * * *</P>
                            <P>
                                (1) 
                                <E T="03">Uncontrollable events.</E>
                                 The actor cannot fulfill the request for access, exchange, or use of electronic health information because of a natural or human-made disaster, public health emergency, public safety incident, war, terrorist attack, civil insurrection, strike or other labor unrest, telecommunication or internet service interruption, or act of military, civil or regulatory authority that in fact negatively impacts the actor's ability to fulfill the request.
                            </P>
                            <STARS/>
                            <P>
                                (3) 
                                <E T="03">Third party seeking modification use.</E>
                                 The request is to enable use of EHI in order to modify EHI provided that the request for such use is not from a health care provider requesting such use from an actor that is its business associate.
                            </P>
                            <P>
                                (4) 
                                <E T="03">Manner exception exhausted.</E>
                                 The actor is unable to fulfill a request for access, exchange, or use of electronic health information because paragraphs (a)(4)(i), (ii), and (iii) of this section are all true; and the actor complied with paragraph (a)(4)(iv) of this section.
                                <PRTPAGE P="1437"/>
                            </P>
                            <P>(i) The actor could not reach agreement with a requestor in accordance with § 171.301(a) or was technically unable to fulfill a request for electronic health information in the manner requested.</P>
                            <P>(ii) The actor offered at least two alternative manners in accordance with § 171.301(b), one of which must use either technology certified to standard(s) adopted in part 170 (§ 171.301(b)(1)(i)) or published content and transport standards consistent with § 171.301(b)(1)(ii).</P>
                            <P>(iii) The actor does not provide the same access, exchange, or use of the requested electronic health information to a substantial number of individuals or entities that are similarly situated to the requester.</P>
                            <P>(iv) In determining whether a requestor is similarly situated under paragraph (a)(4)(iii), an actor shall not discriminate based on:</P>
                            <P>(A) Whether the requestor is an individual as defined in § 171.202(a)(2)</P>
                            <P>(B) The health care provider type and size; and</P>
                            <P>(C) Whether the requestor is a competitor of the actor or whether providing such access, exchange, or use, would facilitate competition with the actor.</P>
                            <P>
                                (5) 
                                <E T="03">Infeasible under the circumstances.</E>
                                 (i) The actor demonstrates, prior to responding to the request pursuant to paragraph (b) of this section, through a contemporaneous written record or other documentation, its consistent and non-discriminatory consideration of the following factors that led to its determination that complying with the request would be infeasible under the circumstances:
                            </P>
                            <P>(A) The type of electronic health information and the purposes for which it may be needed;</P>
                            <P>(B) The cost to the actor of complying with the request in the manner requested;</P>
                            <P>(C) The financial and technical resources available to the actor;</P>
                            <P>(D) Whether the actor's practice is non-discriminatory and the actor provides the same access, exchange, or use of electronic health information to its companies or to its customers, suppliers, partners, and other persons with whom it has a business relationship;</P>
                            <P>(E) Whether the actor owns or has control over a predominant technology, platform, health information exchange, or health information network through which electronic health information is accessed or exchanged; and</P>
                            <P>(F) Why the actor was unable to provide access, exchange, or use of electronic health information consistent with the exception in § 171.301.</P>
                            <P>(ii) In determining whether the circumstances were infeasible under paragraph (a)(3)(i) of this section, it shall not be considered whether the manner requested would have:</P>
                            <P>(A) Facilitated competition with the actor; or</P>
                            <P>(B) Prevented the actor from charging a fee or resulted in a reduced fee.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="171">
                        <AMDPAR>21. Revise § 171.301 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 171.301</SECTNO>
                            <SUBJECT> Manner exception—When will an actor's practice of limiting the manner in which it fulfills a request to access, exchange, or use electronic health information not be considered information blocking?</SUBJECT>
                            <P>An actor's practice of limiting the manner in which it fulfills a request to access, exchange, or use electronic health information will not be considered information blocking when the practice follows the conditions of this section.</P>
                            <P>
                                (a) 
                                <E T="03">Manner requested.</E>
                                 (1) An actor must fulfill a request for electronic health information in any manner requested, unless the actor is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request in the manner requested.
                            </P>
                            <P>(2) If an actor fulfills a request for electronic health information in any manner requested:</P>
                            <P>(i) Any fees charged by the actor in relation to fulfilling the request are not required to satisfy the exception in § 171.302; and</P>
                            <P>(ii) Any license of interoperability elements granted by the actor in relation to fulfilling the request is not required to satisfy the exception in § 171.303.</P>
                            <P>
                                (b) 
                                <E T="03">Alternative manner.</E>
                                 If an actor does not fulfill a request for electronic health information in any manner requested because it is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request in the manner requested, the actor must fulfill the request in an alternative manner, as follows:
                            </P>
                            <P>(1) The actor must fulfill the request without unnecessary delay in the following order of priority, starting with paragraph (b)(1)(i) of this section and only proceeding to the next consecutive paragraph if the actor is technically unable to fulfill the request in the manner identified in a paragraph.</P>
                            <P>(i) Using technology certified to standard(s) adopted in part 170 that is specified by the requestor.</P>
                            <P>(ii) Using content and transport standards specified by the requestor and published by:</P>
                            <P>(A) The Federal Government; or</P>
                            <P>(B) A standards developing organization accredited by the American National Standards Institute.</P>
                            <P>(iii) Using an alternative machine-readable format, including the means to interpret the electronic health information, agreed upon with the requestor.</P>
                            <P>(2) Any fees charged by the actor in relation to fulfilling the request are required to satisfy the exception in § 171.302.</P>
                            <P>(3) Any license of interoperability elements granted by the actor in relation to fulfilling the request is required to satisfy the exception in § 171.303.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="171">
                        <AMDPAR>22. Add Subpart D, consisting of §§ 171.400 through 171.403 to read as follows:</AMDPAR>
                        <SUBPART>
                            <HD SOURCE="HED">
                                Subpart D—Exceptions That Involve Practices Related to Actors' Participation in The Trusted Exchange Framework and Common Agreement (TEFCA
                                <E T="51">SM</E>
                                )
                            </HD>
                        </SUBPART>
                        <CONTENTS>
                            <SECHD>Sec.</SECHD>
                            <SECTNO>171.400 </SECTNO>
                            <SUBJECT>Availability and effect of exceptions.</SUBJECT>
                            <SECTNO>171.401 </SECTNO>
                            <SUBJECT>[Reserved]</SUBJECT>
                            <SECTNO>171.402 </SECTNO>
                            <SUBJECT>[Reserved]</SUBJECT>
                            <SECTNO>171.403 </SECTNO>
                            <SUBJECT>TEFCA manner exception.</SUBJECT>
                        </CONTENTS>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P> 42 U.S.C. 300jj-52; 5 U.S.C. 552.</P>
                        </AUTH>
                        <SECTION>
                            <SECTNO>§ 171.400 </SECTNO>
                            <SUBJECT>Availability and effect of exceptions.</SUBJECT>
                            <P>A practice shall not be treated as information blocking if the actor satisfies an exception to the information blocking provision as set forth in this subpart D by meeting all applicable requirements and conditions of the exception at all relevant times.</P>
                        </SECTION>
                        <SECTION>
                            <SECTNO>§ 171.401 </SECTNO>
                            <SUBJECT>[Reserved].</SUBJECT>
                        </SECTION>
                        <SECTION>
                            <SECTNO>§ 171.402</SECTNO>
                            <SUBJECT> [Reserved].</SUBJECT>
                        </SECTION>
                        <SECTION>
                            <SECTNO>§ 171.403</SECTNO>
                            <SUBJECT>—TEFCA manner exception—When will an actor's practice of limiting the manner in which it fulfills a request to access, exchange, or use electronic health information to only via TEFCA not be considered information blocking?</SUBJECT>
                            <P>An actor's practice of limiting the manner in which it fulfills a request for access, exchange, or use of electronic health information to only via TEFCA will not be considered information blocking when the practice follows the conditions specified in paragraphs (a) through (d) of this section.</P>
                            <P>
                                (a) 
                                <E T="03">Mutually part of TEFCA.</E>
                                 The actor and requestor are both part of TEFCA.
                            </P>
                            <P>
                                (b) 
                                <E T="03">Requestor capability.</E>
                                 The requestor is capable of such access, 
                                <PRTPAGE P="1438"/>
                                exchange, or use of the requested electronic health information from the actor via TEFCA.
                            </P>
                            <P>
                                (c) 
                                <E T="03">Limitation.</E>
                                 The request for access, exchange, or use of EHI is not via the standards adopted in 45 CFR 170.215, including version(s) of those standards approved pursuant to 45 CFR 170.405(b)(8).
                            </P>
                            <P>
                                (d) 
                                <E T="03">Fees and licensing.</E>
                                 (1) Any fees charged by the actor in relation to fulfilling the request are required to satisfy the exception in § 171.302; and
                            </P>
                            <P>(2) Any license of interoperability elements granted by the actor in relation to fulfilling the request is required to satisfy the exception in § 171.303.</P>
                        </SECTION>
                    </REGTEXT>
                    <SIG>
                        <NAME>Xavier Becerra,</NAME>
                        <TITLE>Secretary, Department of Health and Human Services.</TITLE>
                    </SIG>
                </SUPLINF>
                <FRDOC>[FR Doc. 2023-28857 Filed 1-2-24; 4:15 pm]</FRDOC>
                <BILCOD> BILLING CODE 4150-45-P</BILCOD>
            </RULE>
        </RULES>
    </NEWPART>
</FEDREG>
